I am burning a factory image directly into SPI flash and trying to boot. The image was created after building in release with the following command line:
xflash --boot-partition-size 65536 --noinq --factory Modem.xe -o image
The image won't boot. Attaching to the target while running and opening the memory window at address 0x10000 reveals that the contents of the image have been uploaded to ram starting with the 2nd word, however all cores are halted.
In troubleshooting the problem I am noticing the output from XFLASH is inconsistent with what the system specification says is required.
According to the XS1-G system specification, the flash should start with (at address 0x000000):
"The program size s in words - a 32-bit value, least significant byte first."
My image has the following 4 bytes at the start:
0F 80 00 00
This is 0x0000800F, or 32783 words. This is much larger than the image I am trying to upload and seems incorrect.
My current guess is that the CRC is failing because of this and it isn't jumping to the program start.
Am I missing something?
-Thanks!
XS1-G Boot from factory image: Length word seems wrong
-
TjBordelon
- Active Member
- Posts: 39
- Joined: Mon Jul 29, 2013 4:41 pm
-
richard
- Respected Member
- Posts: 318
- Joined: Tue Dec 15, 2009 12:46 am
The XS1-G system specification states:
"The XCore expects each byte to be transferred with the least-significant bit first. Many programmers write bytes into an SPI interface using the most significant bit first, so you may have to reverse the bits in each byte of the image stored in the SPI device."
Because of this when you use xflash to write out an image using -o, the bits in each byte are reversed so you can use the binary with third party programmers. Therefore the first 4 bytes of your image are actually 0x000001F0, or 496 words. xflash boots in multiple stages, and this is the right size for the image at the start of the flash that loads the rest of the application.
I would double check the mode pins are set correctly. If you are still having problems then let the device try and boot from flash, attach a debug adapter and run the following command from the xTIMEcomposer command prompt:
If you post the result of running this command it should give some indication of how far it got through the boot process before it failed.
"The XCore expects each byte to be transferred with the least-significant bit first. Many programmers write bytes into an SPI interface using the most significant bit first, so you may have to reverse the bits in each byte of the image stored in the SPI device."
Because of this when you use xflash to write out an image using -o, the bits in each byte are reversed so you can use the binary with third party programmers. Therefore the first 4 bytes of your image are actually 0x000001F0, or 496 words. xflash boots in multiple stages, and this is the right size for the image at the start of the flash that loads the rest of the application.
I would double check the mode pins are set correctly. If you are still having problems then let the device try and boot from flash, attach a debug adapter and run the following command from the xTIMEcomposer command prompt:
Code: Select all
xrun --dumpstate-
TjBordelon
- Active Member
- Posts: 39
- Joined: Mon Jul 29, 2013 4:41 pm
Thanks Richard!
Loading the file on my PC in a hex editor matches what I see (bit ordering, etc) in the memory window. I assumed that was "correct" but I take it this is actually backwards.
Mode pins are good, and I know it's trying to load the image because if I put text or other jibberish in the image, it shows up in RAM when I power up and toggle reset.
I'll give that a try. I'll also try the tool you suggest.
Loading the file on my PC in a hex editor matches what I see (bit ordering, etc) in the memory window. I assumed that was "correct" but I take it this is actually backwards.
Mode pins are good, and I know it's trying to load the image because if I put text or other jibberish in the image, it shows up in RAM when I power up and toggle reset.
I'll give that a try. I'll also try the tool you suggest.
-
TjBordelon
- Active Member
- Posts: 39
- Joined: Mon Jul 29, 2013 4:41 pm
AWSOME!
I flipped the bits in each BYTE and when I attach to the running target and hit break, things are running. Not working, but running. Now it's back in my court.
A suggestion : Even though the manual says that some programmers reverse the bits, if you follow the exact text you wind up with bits flipped. This is (of course) because the image is flipped for you, however this is never made clear.
I'm good to go for now.
As a side note, I'm running with a 4MBIT unsupported atmel flash. Unsupported because the busy bit sense is backwards so there is no way to get libflash to work with it.
It isn't really mentioned anywhere, but since the flash read command (0x03) is universally supported, even so-called unsupported flash chips like mine seem to work okay. You just can't use libflash. But who cares, right? SPI is 2 small functions.. we don't need no stinkin' lib. :)
I flipped the bits in each BYTE and when I attach to the running target and hit break, things are running. Not working, but running. Now it's back in my court.
A suggestion : Even though the manual says that some programmers reverse the bits, if you follow the exact text you wind up with bits flipped. This is (of course) because the image is flipped for you, however this is never made clear.
I'm good to go for now.
As a side note, I'm running with a 4MBIT unsupported atmel flash. Unsupported because the busy bit sense is backwards so there is no way to get libflash to work with it.
It isn't really mentioned anywhere, but since the flash read command (0x03) is universally supported, even so-called unsupported flash chips like mine seem to work okay. You just can't use libflash. But who cares, right? SPI is 2 small functions.. we don't need no stinkin' lib. :)