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.
Hello! I'm hoping this will be an easy one. I am working with a TMS320F28075 on a new custom board, and so far it is going well. As long as I run the firmware using the debugging, everything works as expected, however I can't seem to get the board to boot out of on-chip flash when my JTAG emulator is disconnected. With the emulator connected, I can use EMU_BOOTCTRL to verify that a value of 0x2A2A0B5A causes the flash to be booted from. I'm able to verify the flash boot by watching the current draw from the board.
When we laid out the board we did not consider the Boot Mode Select Pins, and neither are low at boot. GPIO41 is being pulled up however, so I used the On Chip Flash tool in Code Composer Studio to set Z1_BOOTCTRL to 0x2A2A0B5A. My understanding is that should point both Boot Mode Select Pin 1 and 2 to GPIO41, and that 0x0B will cause the "Get Mode" to select the Flash. I'm able to see in the Memory Browser that Z1_BOOTCTRL remains set after power cycling.
Reading the TRM, it looks like the JTAG nTRST causes EMU_BOOTCTRL to be used, so I've been trying to encourage a flash boot by disconnecting the programming interface, but the board still does not boot from flash.
In a different thread, I saw that CodeStartBranch.asm needed to be included in their project to get flash boot working. I've got F2807x_CodeStartBranch.asm in my project as a "Linked Resource".. I'm not sure if that's what is needed to get it properly included.
Right now I'm at a loss for what to try next... any suggestions are welcome!
Thanks,
-Matt
Hi Matt,
Your configuration look correct. Please make sure you are using correct linker cmd file to map the code_start at address 0x80000. Please check your map file to confirm the same. If that is correct then I would suggest to run the device in stand-alone more with CCS connected. Please follow below steps for the same. -
CPU should halt at main().
Regards,
Vivek Singh
Vivek-
Thanks for the quick reply!
I checked the 28075_FLASH_lnk.cmd file and the .map file generated as part of build -- they show codestart being loaded into a BEGIN section at 0x80000 which has a size of 2.
Here is the linker cmd file sections:
MEMORY { PAGE 0 : /* Program Memory */ /* Memory (RAM/FLASH) blocks can be moved to PAGE1 for data allocation */ /* BEGIN is used for the "boot to Flash" bootloader mode */ BEGIN : origin = 0x080000, length = 0x000002 <SNIP> } SECTIONS { /* Allocate program areas: */ .cinit : > FLASHB PAGE = 0, ALIGN(4) .pinit : > FLASHB, PAGE = 0, ALIGN(4) .text : >> FLASHB | FLASHC | FLASHD | FLASHE PAGE = 0, ALIGN(4) codestart : > BEGIN PAGE = 0, ALIGN(4) <SNIP>
And here is the .map file sections that result:
name origin length used unused attr fill ---------------------- -------- --------- -------- -------- ---- -------- PAGE 0: RAMM0 00000122 000002de 00000000 000002de RWIX RAMLS0 00008000 00000800 00000004 000007fc RWIX RAMLS1 00008800 00000800 00000000 00000800 RWIX RAMLS2 00009000 00000800 00000000 00000800 RWIX RAMLS3 00009800 00000800 00000000 00000800 RWIX RAMLS4 0000a000 00000800 00000000 00000800 RWIX RAMD0 0000b000 00000800 00000000 00000800 RWIX BEGIN 00080000 00000002 00000002 00000000 RWIX <SNIP> codestart * 0 00080000 00000002 00080000 00000002 F2807x_CodeStartBranch.obj (codestart) <SNIP>
I performed the steps you outlined and the CPU halted at main() without an issue.
I tried setting the WD_ENABLE switch in F2807x_CodeStartBranch.asm to 1 in case the watchdog was eating us before we got a chance to disable it in the main code, but that made no difference.
Do you have any other suggestions for me?
Thanks again!
-Matt
Vivek-
I'm happy to report that this problem is resolved; the issue turned out to be a race condition between the pulled-up boot mode pin's rail and the F28075's rail.
Once that race condition was resolved, we're booting from flash as expected and without issues.
I appreciate your attention on this issue!
-Matt