F28M35H52C: Concerto ARM & C2000 .out files to .bin for LM Flash

Paul,
the entry point in your example on M3 should correspond to the start address (0x20005000). for example if you look at blinky dual core example , (C:\ti\controlSUITE\device_support\f28m35x\v208\F28M35x_examples_Dual\blinky\m3) , the code on M3 is built such that ResetISR function is the entry point. The linker command file should be written such that the .resetisr section is loaded to 0x20005000.

The Boot ROM chapter of TRM , section 6.8.1.1 shows how to build a binary image for M3.

The Ethernet boot loader supports loading of code for M3 not for C28x. The M3 application has to take care of this if you want to use Ethernet port for loading the application. The M3 application can download the C28x application and move it to C28x RAMs using one of the ROM loaders supported in C28x ROM (for ex:- using SERPLOOP feature M3 can put the C28x application on UART4 and C28x can boot from SCIA).

hope this helps.

Best Regards
Santosh Athuru

Thanks for the help. Section 6.8.1.1 shows perfectly the tools required to make the bin.

As for loading the C28x using the M3, an example project would be very helpful. What I'm understanding is that the M3 program would act as a gateway in a sense, downloading and then passing the c28x firmware received from the host onto the c28x via inter-core UART. Would an alternative where the ethernet ROM bootloader loads into RAM a combined image, and then the m3 boots and sends the portion of the image in RAM that corresponds to the C28x firmware to the c28x? This would avoid having the M3 open a socket and having to start a separate process on the PC after LM Flash. Thanks.

Paul,
unfortunately we don't have such example for Concerto. But what you outlined seems would be the way I would approach it.

first part is getting the C28x application on to the M3 memories, if the application can fit into the memory available then it is good. Next thing is passing it onto C28x. If the C28x application has to be loaded into RAM then using SCIA boot or SPIBoot using internal loop back feature is one way or you can put copydata type function in to the shared RAMs and assign it to C28x and have C28x boot ROM call this function using IPCFunction call from the MTOCIPC Commands supported by C-Boot ROM to move the application from shared RAMs to C28x RAMs.

if you use SCIA Boot for ex: then you can utilize the SCI BOOT parser in ROM which parses the incoming c28x application hex file and load to C28x RAMs. The C28x boot format is same across legacy devices. If you want to use your custom format then the parser and copy data function can be put in shared RAM and an IPC Functioncall command supported by C-Boot ROM IPC commands can be used.

Best Regards
Santosh Athuru

Again, very helpful. Thanks for laying out some paths forward, I will investigate each.

Would the following way to set it up also work? After the bin is loaded by M3 into shared RAM (where this bin is the M3 program plus the C28x payload as already discussed above), the C2000 boot ROM jumps to a Flash. In the flash, a small program (flashed once at factory then never changes) finds and copies the C2000 program from shared RAM into C28x RAM and then jumps to it. That seems like simplest approach since no use of fancy SCI/SPI/IPC operations, but since I'm still new to this wondering if you can validate the approach. Thanks.

Paul,

yes that should work too and yes it is simpler way to handle this. You will still have to work out the format of the C28x payload, how does the C28x program in flash identify the destination address of the C28x application from shared RAM and how will the C28x program in flash know that it has to go upgrade the FW from shared RAM.

Best Regards
Santosh Athuru