I am looking at both the disassembled copy of the Wixel bootloader binary (extracted by printing out stuff iterating through a CODE pointer) and the USB traffic capture from wixelcmd (obtained using a Beagle USB 12).
First odd thing is that the command to erase the 0x7800 page never appears on the USB traffic
Second odd thing is that inside the bootloader binary calls to locations inside space after 0x7800
Then I actually obtained a dump of the space after 0x7800 and it’s filled with code
The first chunk seems to be just ASCII text with a Pololu copyright notice
I spot structures like jump tables, some access to the SLEEP register, plenty of access to registers around 0xFC##, etc, definitely code and not just blobs
OK so question 1: is all this code required for proper operation of the bootloader? (I am guessing yes)
Question 2: why is it there instead of 0x400-0x800? I mean… if it was below 0x800, the memory write protection fuse can be used to protect it from damage. But now this isn’t possible any more. There must be a good reason because it actually takes more effort to place all that data in a non-continuous block of memory instead of continuous. I’m simply curious.
Question 3: can any of the functions inside be re-used to save me some space for my app? All we need is a header file with the signatures and addresses. I don’t see any references to these functions in the Wixel SDK
The bootloader occupies the first kilobyte (0 to 0x3FF) and the last two kilobytes (0x7800 to 0x7FFF) of the CC2511F32’s flash memory. This is documented in the “The Wixel USB Bootloader” section of the Wixel user’s guide. All of the code in those areas is needed for the bootloader to function. We had to split it up this way because we wanted the bootloader to run before the application, and because we wanted the entire bootloader to be write-protected. The CC2511F32 write protection options do not provide a way to write protect just first the first three or four kilobytes of flash while leaving the rest writable, but they do provide a way to protect the first kilobyte and an adjustable number of kilobytes at the top/end of the flash memory.
I do not think it would be worthwhile to document functions in the bootloader and provide a way for the app to call them. If we release a new version of the bootloader, some of those functions will probably move to different locations, breaking any apps that depend on them. Also, it is hard to guarantee that those functions have the right binary interface and prevent those functions from overwriting RAM that is in use by the application.
–David
Errr this might be a misinterpretation of the datasheet on my part, it says
The size of the write protected area can be set to 0 (no pages), 1, 2, 4, 8, 16, 24, or 32 KB (all pages), starting from top of flash memory and defining a section below this.
Is “top” 0x8000 or 0x0000? If what you are saying is true then the top is 0x8000. I thought it was the other way around. The datasheet really didn’t make that clear. I thought it would make it more robust if top meant 0x0000 and thus the reset vector can never be corrupted
(I was also confused by the “32 bit checksum” that is done at around 0x0127, it made me think that 0x7800 is unprotected, so why is that even being check-summed anyways? Looks like a QA step for the factory, a self-test)
You know the Wixel bootloader is closed source, right?
–David
yea I know but it doesn’t hurt to ask. might be another trick that I can learn.
