• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 80 subscribers
  • Views 398 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Trouble serial programming a F28M35H22

david berger
Prodigy 110 points
Other Parts Discussed in Thread: UNIFLASH

I'm having an issue programming the M3 device via boot ROM. 

The environment for this is a custom kernel on an  ARM chip interacting with the chip over the UARTs, so uniflash and related tools are not an option. 

I can successfully bring up the boot ROM uart, receive pings, etc. However, when I try to write to the device at 0x20000000 I am getting back 0x43 from the get status call. However, I can succesfully write and run applications starting at 0x20005000 (but not 0x20001000, 2000, 3000, 4000). Since the 0x20004000 has reserved space for the bootloader, I get why I can't write there. 

Does the ROM bootloader not do the CSM unlock? These boards are straight from fab, and their flash should be in the reset state. Is there some other issue with the boot ROM not being able to load to these addresses? 

Worst case scenario I can fit a bootstrap kernel into the space I do have available, but I'd prefer to be able to leverage the existing boot code in ROM for this. 

  • 0
    TI__Mastermind 19810 points

    David,

    sorry for delay, I was out of office. 

    Yes the native ROM loaders support only loads to RAM beginning 0x20005000 to end of shared RAMs available on the device. and yes the ROM code doesn't do any CSM unlock.

    Referring to the datasheet (REVH) section 3.2.2 Master subsystem memory map the RAMS C0 and C1 are securable RAMs and boot ROM code runs from unsecure memory so if customer enables CSM on the device and on power up C0 and C1 RAMs become inaccessible to the ROM code the ROM code wouldn;t run properly and device wont boot. So we choose part of C2 RAM for boot ROM Stack and data as C2 RAM in unsecure. Now since part of C2 RAM is reserved for boot and during boot loading using ROM loaders this reserved RAM shouldn't be touched and this creates a hole in the otherwise continuous memory address range of 0x20000000 to 0x20018000.  

    This would be a problem with LM flash programmer tools because the tools expect a continuous memory image. The way the tool works is it sends a COMMAND_DOWNLOAD at the beginning of  load after the autobaud lock and then keeps sending multiple COMMAND_SEND_DATA commands and at the end sends a COMMAND_RESET or COMMAND_RUN. so the download address is given to the bootloader in ROM only once and the ROM loaders keep track of where to load the next block of data based on previous load start address and length.

    so if you can fit your RAM application between 0x20005000 to end of available shared RAMs on the device then you should be good.

    hope this helps.

    Best Regards

    Santosh Athuru

  • 0 in reply to Santosh Athuru
    Prodigy 110 points

    No problem Santosh, it was plenty fast.

    I had worked out most of that; but it's good to verify my own mental model of what was happening. 

    What confused me was this: http://processors.wiki.ti.com/index.php/Code_Security_Module_FAQ_for_C2000#Q:_Will_the_CSM_block_the_boot_loader_running_in_the_boot_ROM.3F. It seems to indicate the F28M35 at the top of the page.

    It would also make some amount of sense for the boot rom to at least do the dummy read of those bytes, so I was surprised when it didn't seem to do so. 

    The RAM available to the boot loader isn't really enough for our main application but we were going to have to make a secondary bootloader anyway to load C28 program data.