Concerto F28M36x - debugger reset core m3 also resets c28

Andreas,

It is correct that the M3 subsystem, the C28x subsystem and the shared resources get reset when the M3 debugger is reset.  However, the C28x subsystem should be in the RUN state to get reset due to M3 debug reset. If the C28x subsystem is under DEBUG HALT when the M3 subsystem sends a debugger reset, the C28x subsystem will not get reset.  But you mentioned that the C28x does not run even in the case where C28x code is just loaded and is in DEBUG HALT (and not executing when the M3 debug reset is given) - Can you confirm this again?

Regarding the CCS notification:  May be we can add a warning to reflect this in the CCS console window by adding a print statement in the gel file's OnReset() function.  Will discuss with team internally.

Please go through section 1.3.2.2 Control Subsystem Reset Handling in TRM at www.ti.com/.../spruhe8c.pdf.

Thanks and regards,

Vamsi

Yes, I can confirm that even if the C28 is in DEBUG HALT, it gets reset. If I then try to step in the debugger or let the program run it does not do anything and if I halt the debugger again it stops at the adress which you can see in the picture above (0x3FF668)

Then the following 2 steps are neccessary to come to a working environment again:

+ issue a CPU reset for C28 core (button click)

+ restart the program (button click)

If one knows this is a bit inconvenient but it took me a while to find out what is the source.

regards

Andreas

Andreas,

I will ask our BootROM expert to comment.

1) Can you confirm that your C28x application is executing fine if there is no M3 debug reset?
2) In the failing case, can you step in and see what instruction is causing the issue? I think it might have to do with something else and not due to M3 debug reset. Try running the BootROM on M3 (just hit resume in CCS for M3 core) after the M3 debug reset and before executing C28x and let me know if it makes a difference.

Thanks and regards,
Vamsi

Andreas,

I don't the problem here. Whenever Master CPU is reset, all the control is reset (as explained in the resets chanpter of the TRM). We don't want the slave CPU to be running when the master CPU is reset, because for ex: the IO configuration is reset.

I believe your main concern is how would C28x code know when M3 is reset? Debugger reset is user induced action so not sure if we must log it in. The basic reset architecture is that is master is reset every thing resets depending on the reset type that reset the master.

The reset cause register is updated for all the resets except for the debug reset, but again debug reset is user induced and doesn't really happen during run time.

In CCS we have to be aware of the below.

1.> Relevant Gel scripts functions will get executed on the debug reset. It helps if we look at the Onreset() functions in GEL scripts and understand them. In stand-alone the boot ROM will take of things that the GEL Script does in debug environment.

2.> If Master gets a debug reset the Slave gets reset as well, but the Slave CPU gel Script won't be run here because user didn;t click the debug reset option on the slave CPU. And user isn;t running the boot ROM on the Master CPU that will initialize the system to run an application correctly.

so with debug resets, what you did seems to be correct. Debug reset master, then debug reset C28x and restart. If you don;t do debug reset C28x and restart the C28x will be either held at reset of it will be running C-Boot ROM.

Hope this helps.

Best Regards

Santosh Athuru

Hi Santosh,

yes that is exactly what I do in your (2.) explanation.

But for me as a Developer and User of CCS it is hard to understand that the CCS does not show that also the C28 core is reset but in fact it is done.

In terms of user-friendlyness I as a developer would really appreciate, to see that also the C28 core is reset.

For either of the cores I can see in the debugger that it shows some hex-address after I click the CPU-reset button. But I don't see that for C28-core if the M3 core is reset. Despite the hardware makes that reset. So it seems that the C28 core is still on a valid program adress.

I think this is really confusing!

(A way of correcting this could be from my point of view to execute the GEL-script of C28 out of the M3-GEL script)

kind regards

Andreas