• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 30 subscribers
  • Views 753 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

IWR6843AOP: there is a size limitation on the bin file when flashing via SPI?

Tony Simple
Intellectual 390 points
Part Number: IWR6843AOP
Other Parts Discussed in Thread: IWR6843, UNIFLASH

Hi expert,

I am trying to boot IWR6843 via SPI according to Section 2.2 boot mode in the IWR6843 Bootloader Flow, but got a strange problem by the following steps:

1. Build a firmware A as the baseline for the People Counting as example;
2. Firmware A works fine on EVM with UniFlash;
3. Firmware A can be flashed via SPI to our board and everything works fine;
4. Add a couple of code in baseline and build a firmware B;
5. Firmware B also works fine on EVM with UniFlash;
6. Firmware B cannot be flashed via SPI since neither the interruption nor message is returned. AR_AE_MSS_BOOTERRORSTATUS_SB is expected to be returned like Step 3

From the point of view of flashing via SPI, the only difference is that B is only 2K larger than A, 645770 bytes and 647236 bytes respectively. Identical program is used for both cases.

Does it mean that there is a size limitation on the bin file when flashing via SPI?

Thanks.

Tony

  • 0
    TI__Genius 14415 points

    Hi Tony,

    Can you please confirm what you mean by flashing? Typically the flow via Uniflash will pass the image through the device to actually write to the external flash device. This is not always the case but you would have to make some changes to uniflash. WHen loading via SPI, there is no flash attached, so you are really just loading the internal RAM. Since these are fairly different and sometimes involve power cycles I want to make sure. It sounds like you know the difference but I just want to be sure what you are asking.

    Where is the memory located that you are trying to add to the image? Are you sure there is enough room? I seems there should be enough since it appears to be working via uniflash, but I would like to confirm it should.

    Also, since you are presumably still in some part of the bootloader when this SPI issue occurs, can you please check the bootloader error register?

    To read this

    1. power on the device normally
    2. launch the XDS debugger in CCS
    3. connect to the MSS core (do not load anything).
    4. Open the memory browser window and browse to location 0x08009C50.

    The memory location above holds the error status register. If this is 0 there is no error. The errors can be decoded from the Interface Control Document, located in the DFP download. The error codes are in table 7.3, "Error codes for boot on SPI"

    Hopefully this helps find the error. I don't think there should be a file size limitation other than the memory available in the device.
    Regards,
    Jackson
  • 0 in reply to Jackson Thomas
    Intellectual 390 points

    Hi Jackson,

    Thanks for your reponse. What I mean in the previous is to load firmware via SPI and the flash step is just to make sure the used firmware works. 

    I did follow the Interface Control Document and every package except the last one has an OK response from Radar. Actually, there is no response at all for the last package. I built another one yestoday, which is 256 bytes smaller than Firmware B and can be successfully loaded into Radar. 

    Still need to resolve this since that was a temporary solution only.

    Best wishes,

    Tony

  • 0 in reply to Tony Simple
    TI__Genius 14415 points

    Hi Tony,

    Were you able to test if there are errors after sending the larger file over SPI?

    Also, are you using uniflash to load directly to the RAM, or are you programing the FLASH chip on the board? There are some difference is what is allowed when flash is connected to the board, some things like calibration save info to the flash, so if that is what you have added it won't work via SPI. But I think this is not the case for you.

    In addition to removing 256 bytes, what was the memory you removed? Was it from a specific memory section? Are you just generating the image based on combining the three images for BSS,MSS,DSS in CCS? Or is there another way you are generating this image that has more info for the flash chip?

    Regards,

    Jackson

  • 0 in reply to Jackson Thomas
    Intellectual 390 points

    Hi Jackson,

    Thanks for your thorough considerations. 

    Jackson Thomas said:
    Were you able to test if there are errors after sending the larger file over SPI?

    Yes, I tested with a wrong CRC attached on a package.

    Jackson Thomas said:
    Also, are you using uniflash to load directly to the RAM, or are you programing the FLASH chip on the board? There are some difference is what is allowed when flash is connected to the board, some things like calibration save info to the flash, so if that is what you have added it won't work via SPI. But I think this is not the case for you.

    That was not my case.

    Jackson Thomas said:
    In addition to removing 256 bytes, what was the memory you removed? Was it from a specific memory section? Are you just generating the image based on combining the three images for BSS,MSS,DSS in CCS? Or is there another way you are generating this image that has more info for the flash chip?

    The memory I removed includes a couple of print statements and a few loops. CCS is used to test and generate the firmware, and then my program running on another MCU loads that firmware into Radar.

    Hope the above info could help on this issue.

    Thanks again for you help.

    Best wishes,

    Tony

  • 0 in reply to Tony Simple
    TI__Genius 14415 points

    Hi Tony,

    I want to confirm a few more things. It seems that you are already stripping off the 32bit CRC from the end of the auto-generated image? Would like to confirm you have done this for all images. It seems you are since the smaller images did boot, but just to clarify.

    Also, can you say what the packet size is for the SPI load you are using?

    Were you able to check for bootloader errors after sending the large image? If so were there no errors? If there were no errors, the program may have been kicked off. If this is the case, you should be able to connect via CCS (after loading via SPI), load the symbols only for your project, and see where the system threw an error. This isn't always helpful, but sometimes can point us to where the issue is originating at least.

    Regards,

    Jackson

  • 0 in reply to Jackson Thomas
    Intellectual 390 points

    Hi Jakson,

    Jackson Thomas said:
    I want to confirm a few more things. It seems that you are already stripping off the 32bit CRC from the end of the auto-generated image? Would like to confirm you have done this for all images. It seems you are since the smaller images did boot, but just to clarify.

    Yes.

    Jackson Thomas said:
    Also, can you say what the packet size is for the SPI load you are using?

    The maximum package used is 240 bytes. 

    Jackson Thomas said:
    Were you able to check for bootloader errors after sending the large image? If so were there no errors?

    No, we cannot. There is no response at all after the last package is sent.

    Jackson Thomas said:
    If so were there no errors? If there were no errors, the program may have been kicked off.

    Do you mean the boot loader will kickoff the program and send a confirmed package after it receives the last packge of a program? Otherwise, the confirm package should be sent first and then kickoff the program.

    Jackson Thomas said:
    If this is the case, you should be able to connect via CCS (after loading via SPI), load the symbols only for your project, and see where the system threw an error.

    The program is running on a cusomized board and XDS100 is not available there. 

    Thanks again for your help.

    Best wishes,

    Tony

  • 0 in reply to Tony Simple
    TI__Genius 14415 points

    Hi Tony,

    Understand about the final packet response. I am checking with the bootloader designers if this is intended behavior. 

    Do you have any JTAG access to the IWR device on the board? You may need to use an external XDS110 to connect in CCS. If the program is being started then the SPI line won't be responsive. What is the intended behavior and how do you know it is not running? If the peripherals are unresponsive due to an error, JTAG will be the only way to communicate with the device.

    Also, I suppose you are not testing the images over UART/flash on the same board? Are you using a TI EVM for those tests?

    Thanks,

    Jackson

  • 0 in reply to Jackson Thomas
    TI__Genius 14415 points

    Hi Tony,

    I wanted to follow up and see if there was any progress here? Have you tried using a smaller packet size when loading the larger programs? There shouldn't be an issue but we have seen this cause issues on other devices. Can you try something like 232bytes instead of 240?

    Any luck with the JTAG debugging?

    Regards,

    Jackson