Re-loading / re-starting debug session with MQX code on the M4 core of the VF61xxx

[dry]

Are you able to do this when working on the M4 core side of the VF61 SoC, with MQX based project, without resetting the whole SoC? (either through full por,  wd reset, external pin reset).

You debugging, then you decide to modify the code, rebuild, and re-load it and restart debugging. Are you able to do this without resetting the entire system? I cannot, and I don't understand why.

On first system power on and start, I can connect with hw debugger, upload firmware, and start debugging. I can also restart the debug session with same code, from beginning, and code always runs, debugging works good.

If I modify code, and upload it, then I get into trouble. The only thing I seems get consistently working is I get into main() which then calls _mqx. From then things just "don't work".  The code seems to run, but gets stuck in various places,  not consistent from restart to restart. Break points don't seem to (always) work either, with the exception of the one in main which I hit constantly (and also if I set it in MQX bootloader, that is spot-on 100%).

It fails or gets stuck in different places. It can be bsp init,  e.g. it can get stuck on call to enabling dcache, yet, if I single step that call, then it runs.  It can get stuck in unexpected interrupt call handler, which it being called indefinitely.  It can get stuck on application code testing for static variables being allocated properly,  which sometimes appear not to.

It's just a _total_chaos_, which makes me think I'm crazy.

Yet, _exactly_same_ modified code/binary runs superbly fine if first do full system reset with say wdog A5 reset ( I can trigger it from A5 side).  Then the system comes back from this total chaos, and I'm back at being able to work normally.

Any explanations & suggestions please...?

[Carlos_Musich]

Hi DRY,

the A5 core is the boot strap processor, so it is in charge of configuring the clocks and peripherals of M4. So I think that misbehavior is because of the lack of configuration.

Best regards,
Carlos

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[dry]

Hi Carlos,

Thanks for providing the feedback.

Could you clarify a bit what you mean? I'm not sure I understand it.

Since A5 is boot strap processor, yes it will configure (actually it's U-boot that runs on A5 in my tests, so this is where that happens) the main clocks for both cores. Then when I upload & run the M4 code with the debugger, the M4 code configures the peripherals that it needs.

I 've seen MQX init code may bypass certain setups, on assumption that it was done elsewhere. Like the macro BSPCFG_ENABLE_CLKTREE_MGMT is disabled in my configuration so MQX accepts the base clocking as given, and should only configure the clocks for peripherals the M4 controls.

But all in all, if there was no system reset, and A5 is still running, the base clocks configuration thus should still be there..

It's the M4 that is being either restarted (restart on-going debug session) or reset (reset, upload new code & start debug session).

Are you saying that in the case where the debugger resets the M4 core & uploads new firmware, the M4 will loose it's clock configuration which was done by the A5?  But how would then the debug session run successfully on M4 on the first time the system booted? Something else is missing

[Carlos_Musich]

Hi D. RY,

When you restart M4 session you just move the memory pointer and it will be not synchronized with Cortex-A. Cortex-A is the one that provides M4 access to the bus, so if the initialization script does not run again M4 will not have access to the bus.

Best regards,
Carlos

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[dry]

Hi Carlos,

Would be nice to get some more clarity on that initialization script you referred to?

[dry]

> ..Cortex-A is the one that provides M4 access to the bus

I do want to figure this out for myself, so if you could point may be to the section in Vybrid manual concerning this,

in particular in relation to while the system (M4) is under the hw JTAG control.

In any case, if you know of way to fix my restart issue, I welcome it.

[dry]

Hi Carlos,

I think you lost me unfortunately.

> When you restart M4 session..

In this is case when you hit 'restart debug' : the action (correct?) executed by hw debug is halt the M4 core, start from beginning of the image.

>  you just move the memory pointer  ...

Adjusting PC and SP , per debugger setting

This is where I seems (or i tend to think),  have no issues with - the session restarts Ok.

Sorry to repeat my original post: what I see is the start (stop, start new debug session) of updated code doesn't work : the steps (correct?) executed by hw here is reset the M4 core, halt, upload new fw, start from beginning of image.

> .so if the initialization script does not run again .

Which initialization script?   could you share it