CCS/TMS320F28377D: Debug: Get the following error on CPU 2

Jari,

If you copy the program from flash to ram, sometimes it doesn't stop at the beginning of main function during debug. If your problem is something like that, please have a look at the following link.

e2e.ti.com/.../714009

Regards,
Hakan

Jari

That address in ROM indicates CPU2 entered into the idle mode where it waits for IPC command to boot. Sounds like CPU2 is getting reset. Does it get to main? If not, may want to disable the watchdog.

Also check out the link Hakan provided.

Best regards
Chris

Hi Christopher,

Thanks for your reply. But when I load the program into the demo board of TI TMS320F28379D， it can be run well ( target file is replaced with TMS320F28379D). And when I replace the program with TI demo program ( blink_DC) to program with my custom board, it got the same above result. The CCS will report:

C28xx_CPU2: Trouble setting breakpoint with the action "remain halted"at 0xc056: (Error -1066 @ 0xC056) Unable to set/clear requested breakpoint.

This is a new chip, We didn't set any breakpoint before, I don't know why ?

Could you please give some advice?

thanks!

Please make sure you have CPU1 also connected to CCS and halted.

Error is for address 0xC056 which GS0 RAM. Are you using that RAM for CPU2 code? If yes then please note that by default this RAM is assigned to CPU1 hence CPU2 can not execute code from GS0 unless CPU1 code (or Gel file) assign it to CPU2.

Also make sure both CPUs are halted before programming.

Best regards
Chris

Hi Chris,

Thanks for your kind help. All of code in .TI.ramfunc is assigned to LS RAM, I didn't use the GS0 RAM. I re-tested the board, when the program is set by Standalone mode (use IPCbootCPU2 function ()), both of CPU1 and CPU2 works well. But CCS still reports the error.
And when the debug of CPU1 and CPU2 is reside in RAM and run in RAM with emulator connected, both of them can work normally.
When the program is set by flash Debug, CPU2 won't work well. It is not convenient to debug in flash.

So I think one reason may be that: CPU2 may not work normally during the Emulation Boot flow, I check the EMUBOOTCTRL register located at 0xD00 in CPU1 is 0xA494035A. It seem that CPU1 works at get-mode. And CPU1 OTP BOOTCTRL1 and BooTCTRL2 is 0xFFFF, so it is ok for CPU1 to run into the flash mode. Since CPU2 didn’t work, so it can’t get any information about CPU2.

Above the error reports is a hint of CCS:

C28xx_CPU2: If erase/program (E/P) operation is being done on one core, the other core should not execute from shared-RAM (SR) as they are used for the E/P code. Also, CPU1 will be halted to determine SR ownership for the CPU which will run the Flash Plugin code, after which CPU1 will be set to run its application. User code execution from SR could commence after both flash banks are programmed.

According to above description, Is there such a possibility that CPU1 is erase/program the GS0 share-RAM, But the CPU2 would like to set the breakpoints in GS0RAM, so it is prohibited. But I don’t know why CPU2 use GS0RAM during debug of flash. Can you elaborate on these?


Thanks!

Hi Chris,

Thanks for your help, GS0 in the "2837xD_FLASH_lnk_cpu1" and "2837xD_FLASH_lnk_cpu2" is the SHARERAMGS0 area. By default, CPU1 has the ownship of GS0, the program of "TI.ramfunctionc'' is assigned into LSRAM of CPU2.
And why CPU2 can auto runing after the program is loaded in debug mode.

Hello

Yes, ideally most debug should be done from RAM.
I don't believe flash programming should be using GS0, I will check.

You try following the steps described by Vamsi in this post: e2e.ti.com/.../676413

Also for autorun: processors.wiki.ti.com/.../Debug_Handbook_for_CCS

Best regards
Chris

Hi Chris,

Thanks!

It seems that the initialization value of the Z1_BOOTCTRL  and Z2_BOOTCTRL register is abnormal in our custom board, compared with other proper working chips. Since this is a user-configurable DCSM OTP, its default value is set by TI. I didn’t use the On-Chip flash option to erase this register, Because it is very risky, we can only change it once. May waste the chip if it is set incorrectly.

                                       The BootCtrl register of CPU2 in my custom

The BootCtrl register in other working properly board that I have tested display as 0xFFFFFFFF according to the TRM

 The default value on the panel of On-chip Flash of CCS is 0xFFFFFFFF, since this register is one time program (OTP) register, I didn’t program the default value now. If it is not planned well, the chip may be wasted!  I don't know whether this is the reason that my CPU2 couldn’t work properly.

Could you please give some advice?

 

Thanks!

Hi,

Yes, Zx_BOOTCTRL location in USER OTP are one time programmable and can not be erased. These are not programmed on fresh part. These are programmed by customers only. Can you check the value in OTP location as well and confirm it's indeed 0x0 ? If yes, then it must have got programmed due to incorrect linker cmd file.

Regards,

Vivek Singh

Hi Vivek,

Thanks for your reply!
During the debug I only can find the BootCtrl register in the Register window of CCS as the above picture, since its dummy
read is issued to address location of Z1_BOOTCTRL in OTP., It is indeed the value of 0x000.
How can I find the OTP Register value?

What do you mean I must have got programmed due to incorrect linker cmd file? could you please elaborate on this details?
I have been using the 2837xD_FLASH_lnk_cpu2.cmd file that TI has provided.
I didn't find any code relevant with OTP Z1_BOOTCTRL register setting. My chip is a new chip that just purchased from TI. Why this happen?
Why the TI evm and other chip set the default value for OTP?
By the way,
The EMUBOOTCTRL register in our custom board of CPU2 is 0xCE66025A, according to boot mode in TRM, since the EMUKEY is 0x5A, the BOOTCTRL register of boot mode is 0x02, So CPU2 will in wait boot mode.
How can CPU2 get out the mode of Wait Boot Mode?
Does the OTP BOOTCTRL of CPU2 have influence on the boot mode choice of CPU2, if EMUBOOTCTRL Register is not 0xXXXX035A. Since the boot mode bit of EMUBOOTCTRL Register is 0x03, CPU2 may enter the get boot mode. The OTP Z1_BOOTCTRL Register may be used.

Thanks!

Hello

In regards to your boot flow questions, CPU2 can get out wait boot when it receives the boot IPC command from CPU1 application.
CPU2 OTP BOOTCTRL will have an effect in standalone (no debugger) or when emulating using GetBoot like you are. It will read the value set in BOOTCTRL.BMODE and when doing emulation boot with Get Boot set in EMUBOOTCTRL, it will set the boot mode to wait boot if the GetBoot bootmode isn't flash boot.
The boot code is available in C2000Ware (under libraries) for reference.

Best regards
Chris