Problem with custom bootloader

Discussion around product based on ARM Cortex M3 core.
This forum will be discontinued soon.

Moderators: nferre, ncollot

CollinK
Posts: 2
Joined: Sun Aug 30, 2015 11:27 pm

Problem with custom bootloader

Sun Aug 30, 2015 11:37 pm

I'm writing a bootloader of sorts that can accept new firmware over canbus and write it to FLASH. To do this I'm trying to use the flash as the two sections (FLASH0, FLASH1) such that it writes the new firmware to whichever section is not being used to run the program. The program is it's own bootloader this way. I've actually been pretty successful in that regard since I can send the firmware and write it to the flash section not currently being used for running the program. If I set boot mode to go to the ROM after writing the new firmware I can use SAMBA to read back the whole 512k flash space and see that both copies are properly in FLASH and at the two sections (one at the start of FLASH and one 256K up in the second flash section). But, I've noticed that when samba writes a raw binary it places some extra data after the raw binary. This extra data seems to form little endian 32 bit values like: 0x20070734 (so it was stored 34, 07, 07, 20 in flash). These extra values seem to be within SRAM but where is SAMBA getting these extra values? They aren't found at the end of the raw binary. When I try to boot the firmware I flashed via my "sort of" bootloader the code just crashes. This makes me think that perhaps those extra values at the end are important but I can't find a reference for what they're supposed to be or where I'm supposed to generate them from. Can anyone point me in the proper direction?

On a related note, when reading flash space via samba does it not reorganize the flash space? GPNVM bit 2 is supposed to reorganize flash space to switch whether FLASH0 or FLASH1 is first in memory but as far as I can tell this doesn't change the ordering for SAMBA.
YogiBear
Posts: 5
Joined: Tue Nov 24, 2015 4:55 pm

Re: Problem with custom bootloader

Sat Dec 03, 2016 4:40 pm

If your code is under 64K, you should be OK with the Dual Bank method.

If your code is > 64K, there is a bug in the SAM3X8E that prevents the Dual Bank method from working.

This is documented in chapter 49, SAM3XA Series Errata, section 49.1.3 Flash: Boot Flash Programming Mapping is Wrong, it states:
"GPNVM2 enables to select if Flash0 or Flash1 is used for the boot. But when GPNVM2is set, only the first 64 Kbytes of the Flash 1 are seen in the Boot Memory. The rest of the Boot memory corresponds to Flash 0 content.

Problem Fix/Workaround
No fix required if the code size is less than 64Kbytes. Otherwise the software needs to take into account this limitation if GPNVM2 is used."

This means that this dual banking scheme will not work if the code is > 64K.

I wrote a Can Bus bootloader and used the Single Bank method. Flash1 is the buffer area. Once the firmware is downloaded, I validate it. Then it gets copied from Flash1 to Flash0. Since you cannot copy to flash that you are executing from, I use the flash_write function that is based on the EFC functions that operate from ROM. After the copy, you jump to the firmware now located at 0x80000.

Return to “SAM3 Cortex-M3 MCU”

Who is online

Users browsing this forum: No registered users and 4 guests