I am trying to debug a Concerto application that I am developing utilizing both the M3 and C28 cores and I am getting weird behavior when connected to the debugger.
The behavior I am observing is that when I cold-boot the device with no debugger attached, both cores start up as expected. The M3 streams back data to a server application and the C28 toggles an LED based on IPC data transfer. When I try to run the debugger (without the GEL files), the C28 gets stuck at the IDLE instruction at the end of the Boot ROM.
After looking at a number of the other BootROM related posts, I have double checked my GEL file settings, and even tried this on a different computer (to rule out some corruption within Windows).
I have also looked at the CTOMIPCBOOOTSTS register which is leading me to believe that something is not right.
The value of the register is 0x003FEDAA
In looking at Section 6.6.11 (pg 576) of the Rev B TRG, this decodes as:
C-Boot Rom Detected iTRAP
PIE VECTOR ADDRESS MISMATCH
Missing 10MHz INTOSC
Boot Started
C_BOOTROM_BOOTSTS_CTOM_BOO_CMD_NAK_STATUS_BUSY_WITH_BOOT
C_BOOTROM_BOOTSTS_CTOM_BOOT_CMD_ACK
C_BOOTROM_BOOTSTS_CTOM_CONTROL_SYSTEM_START_BOOT
This is the register reading taken after resetting both devices, starting the C28, Starting the M3, then pausing both devices. I am getting data back over the Ethernet from the M3 core, so I know it's running OK, but the C28 is still at the IDLE step.
I have also taken the suggestion of running the RAM Init functions from the 4087.ipc_raminit.c from another forum post. This had no success.
Any ideas what is going on to cause this? If there is any other data that would help debug the behavior, let me know and I can get it.
My system specifics are:
Concerto Control Card with Experimenter's Kit
CCS v5.1.1.00031
ControlSuite (I've tried using the v110 and v120 support files)
Regards,
Drew Hintz
Drew,
When the debugger is connected, do you want to debug the C-BootROM flow or you just want to debug the application on Control subsystem Flash.
As you mentioned things work in the cold boot, so the proceedure of Master application sending the boot command to C-Boot ROM and C-Boot ROM starting the application in flash is flushed out and working - correct?
Andrew HintzThe behavior I am observing is that when I cold-boot the device with no debugger attached, both cores start up as expected. The M3 streams back data to a server application and the C28 toggles an LED based on IPC data transfer. When I try to run the debugger (without the GEL files), the C28 gets stuck at the IDLE instruction at the end of the Boot ROM.
Now, with the assumption that you want to debug the C28x flash application and M3 flash application - the easiest way to do it is
>> 1 . on M3 applicaiton comment out the code or function that sends Boot Mode IPC to C-Boot ROM. Because when you are debugging you don;t have C-Boot ROM running right?
>> 2. Now you can update the application, re-build and flash and debug it as you like.
>> 3. on C28x side, when debugging (keep the GEL files as they are) you would normally flash the application and start the application from application entry point, C-Boot ROM doesn't come into the flow here.
>> 4.> after both M3 and C28x flash applications are debugged and finalized, put back the code that was commented out in step 1 above and flash the updated application and run the device in stand-alone mode.
Does the above answer the questions, please let us know if you have more questions.
Best Regards
Santosh
Santosh,
That is about where I was coming to, so if that's how I need to debug, that's ok. My concern is more from the fact that I used to be able to debug both from FLASH with the same project, the same board, etc. I know there's the bug in the boot ROM, but I'm just curious what might have changed to change the behavior that used to work.
Thanks for providing a suggestion that works for me.
Drew
something must have changed in the application . May be the application is doing something wrong this time or it was doing something wrong last time - I would start by looking at the changes done to the application or debug environment. If you have a back up of last known working code try that. Changes to watch out for are - RAM usage changes, flash init changes, hardware init changes, clocking changes.
hope that helps.