TMS320F28388D: EPWM controlled by CPU2 don't start outside debug

Hello Adrien,

Adrien Thurin said:

The problem only occurs when booting from flash : all PWMs work fine in debug mode.

Lets make sure you are following the proper sequence required for CPU boot flow :

1) CPU2 boot ROM uses the CPU1TOCPU2IPCBOOTMODE register to determine the boot mode configuration. Do you have proper config here ?

2) Also refer to the flowchart 5.5.2 CPU2 Boot Flow in Technical reference manual ROM Code and Peripheral Booting Chapter and make sure everything here is taken care off. 

Thanks!

Hello Prarthan,

Thanks for your answer ! 

For the IPC configuration, I copied (or at least I tried) example ipc_ex3_basic_sysconfig. CPU2 boot mode is "boot from flash" in sysconfig. Both CPUs have the IPC sync like in the example, and the LED associated with CPU1 toggles nicely, so I assume CPU2 started (unless the IPC sync has a timeout ?). 

Also, when I put a LED toggle in the infinite loop rather than in a PWM-dependant ISR, it does toggle, which suggests it is a PWM-related issue, not a boot issue. 

Thanks in advance for your help,

Best regards,

Adrien

Adrien,

Adrien Thurin said:

Also, when I put a LED toggle in the infinite loop rather than in a PWM-dependant ISR, it does toggle, which suggests it is a PWM-related issue, not a boot issue. 

What triggers that epwm related ISR ?

Adrien Thurin said:

Turns out the EPWM in question are those controlled by CPU2. Those controlled by CPU1 seem to work fine

Can we change the ownership of these pwm to CPU1 and check if they work fine ?

Also check the CPU2 boot status just to make sure.

Thanks!

Prarthan,

Prarthan Bhatt said:

What triggers that epwm related ISR ?

As I said in my first prost, EPWM trigger SOC, EOC trigger ADC INT. A counter is incremented in the ADC INT, and the LED toggles when the counter exceeds a certain value.

Prarthan Bhatt said:

Can we change the ownership of these pwm to CPU1 and check if they work fine ?

I will try, but it is not easy. There doesn't seem to be easy ways to "move" one peripheral from one core to the other in sysconfig. I will let you know how it goes.

Prarthan Bhatt said:

Also check the CPU2 boot status just to make sure.

I don't know how to do that. I can't access the register directly since the issue doesn't appear in debug mode, and I don't have any communication protocol (yet) implemented.

If it is just 1 bit, maybe I can output it to a GPIO ?

Thanks for your help

Adrien,

Adrien Thurin said:

As I said in my first prost, EPWM trigger SOC, EOC trigger ADC INT. A counter is incremented in the ADC INT, and the LED toggles when the counter exceeds a certain value.

I meant to ask, what event triggers EPWM to SOC ?

Can you also check if the event the supposed to trigger SOC is happening ? Check the ETFLG and see if the soc is triggered

Can you share the code here, I can have a look ?

Thanks!

Prarthan,

Prarthan Bhatt said:

I meant to ask, what event triggers EPWM to SOC ?

SOC trigger is TBCTR = 0.

Prarthan Bhatt said:

Can you also check if the event the supposed to trigger SOC is happening ? Check the ETFLG and see if the soc is triggered

It is triggered in debug mode. I haven't checked otherwise, I would have to randomly check the register and hope to hit the right timing ?

That being said, EPWMs are configured to have a duty cycle in sysconfig, without going through the interrupt. In debug mode, I see some output on the PWM pin, but there is nothing outside of debug. Some peripherals are configured, since I can toggle the GPIO in the infinite loop, but who knows if the PWM is the only one with an issue...

Prarthan Bhatt said:

Can you share the code here, I can have a look ?

I would rather not share it publicly, but I would be happy to send you the whole project with some private / secure means (TI drive ? Or I can send you a Wetransfer ?)

Best regards,

Hi Adrien,

If everything works well in debug mode. Looks like something is not working out when you are coming out of debug mode to standalone flash boot mode.

Also Please check with below steps : 

1)  Do you have boot mode pins configured for Flash boot?

2) Refer to these previous posts might solve your issue ;
https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/925450/ccs-launchxl-f28379d-cpu2-not-booting-from-flash-after-reset

3) Lets try getting the emulation session to mimic the standalone boot to debug this properly.

After you connect to the device(that is already flashed, and with the offending code), in CCS go to Run->Reset.  Then Go to Scripts->EMU_BOOT->FLash Boot.  This will program the EMU boot field in RAM and the BROM will intercept this and mimic the boot from flash that would happen in standalone.  You should be able to follow along with the code to see what is/is not happening or if it is what you expect.

Thanks!

Hi Prarthan,

Prarthan Bhatt said:

1)  Do you have boot mode pins configured for Flash boot?

S2 on the controlcard have both switch set to "off". I read 1 on both GPIO 72 and 84.

I assume this means boot from flash, since CPU1 starts from flash correctly.

I have also run some tests with IPC, CPU2 is apparently running, because I can send some messages from CPU1 to CP2 and back, and have these messages affect the LED blinking of CPU1  (thus viewing CPU2 is running outside of debug). IPC messages are send in a timer interrupt, so timers are properly configured even outside debug... 

Prarthan Bhatt said:

2) Refer to these previous posts might solve your issue ;
https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/925450/ccs-launchxl-f28379d-cpu2-not-booting-from-flash-after-reset

It seems to be a different issue. In this post, CPU2 doesn't start at all. In my case, it boots from flash, some code runs (infinite loop, timer interrupts). The problème lies elsewhere, in the relationship between boot from flash and pwm configuration maybe ? 

Prarthan Bhatt said:

3) Lets try getting the emulation session to mimic the standalone boot to debug this properly.

After you connect to the device(that is already flashed, and with the offending code), in CCS go to Run->Reset.  Then Go to Scripts->EMU_BOOT->FLash Boot.  This will program the EMU boot field in RAM and the BROM will intercept this and mimic the boot from flash that would happen in standalone.  You should be able to follow along with the code to see what is/is not happening or if it is what you expect.

I have tried, but absolutely nothing happens when I click on Scripts->EMU_BOOT->FLash Boot. 

Is there a (secure) way I can send you my project, as you suggested ?

Best regards,

Adrien

Adrien Thurin said:

I have tried, but absolutely nothing happens when I click on Scripts->EMU_BOOT->FLash Boot. 

So when you do the above press reset, upon reset (xrsn) you application would start from flash and you can view that in disassembly view and step through the code and see whats going wrong. Also a video tutorial for the same : https://www.youtube.com/watch?v=lYcB1O3FpOo

I have sent you a connect request :  https://e2e.ti.com/support/site-support-group/site-support/f/site-support-forum/693323/faq-how-do-i-send-and-receive-a-private-message-on-e2e-support-forums

Please accept and send me the zipped folder on message privately

Thanks!

Hi Adrien,

I will re-assign this thread to multi-core SME for the issue that you are facing.

Were you able to try the above recommendations ?

Thanks!

Prarthan

Adrien,

I see that this thread has a long period without an update, was there some activity offline that I should be aware of? 

Best Regards,

Ben Collier

Hi Ben,

I haven't had time to explore this issue, as I have been quite busy with IPC issues (among other things).

Best regards,

Adrien

Ok, I will mark this thread as on hold. 

Hi Ben,

As recommended by Prarthan, I have moved one of the PWMs with the issue to CPU1. The issue goes away.

As I mentionned, I don't think it is a "strict" boot issue. CPU1 waits an IPC sync from CPU2 to run its application code, and the application runs fine. Also, I can toggle a GPIO in CPU2's infinite loop. Therefore, there is something special about EPWMs controlled by CPU2.

Best regards,

Adrien

Adrien,

You are also able to run the code fine when the debug probe is connected? That is very strange.

Hi Ben,

Yes, it all runs fine when the probe is connected.

I shared the project with Prarthan, did he passe the code along to you ? If not, do you want me to send it to you ? In case there is an important element I (unknowingly) failed to share here...

Adrien,

I will sync up with Prarthan and I will take another look.

Best Regards,

Ben Collier

Hi Ben,

Did you get a chance to look at this issue ?

Best regards,

Adrien

Sorry for the delay, will get back to you on this tomorrow. 

Sorry, but I will need another day. I got the code from Prarthan, but have not been able to try it myself yet. 

Adrien,

I was able to replicate your issue, it seems that there is a problem with CPU2 booting in your project since there is a problem with the GPIOs toggling in your code as well.

I was not able to diagnose the issue in the small amount of time that I was able to spend on this issue, so I can only recommend that you compare your project with one of our working examples to see what is different that could cause CPU2 boot issues. 

Best Regards,

Ben Collier

Hi Ben,

As explained above, there is no issue with CPU2 boot. The GPIO doesn't toggle because it is linked to the PWM (PWM triggers ADC SOC, ADC EOC triggers ADC INT, ADC INT increments a counter, LED blinks if the counter reaches a certain value, and resets the counter). When the GPIO is not connected to the PWM (ie counters incremented in the infinite loop instead of an INT triggered indirectly by the PWM), it blinks as expected.

Moreover (again, as explained above), CPU1 wouldn't run if CPU2 didn't, due to the IPC sync command.

Hence the issue is connected to the PWM, and not just a "general" boot issue.

Is there something that needs to be done to start the PWMs properly when controlled by CPU2 ?

Best regards,

Adrien

Adrien,

I'll take another look, but I can't think of anything related to PWM that would be different between standalone mode and debug mode. 

Hi Benjamin,

I understand, I didn't find either anything in the documentation of the PWM that would be different between standalone and debug mode. However ... something does, as we both saw. You can easily see that it is not just a boot issue, that the code goes to the infinite loop (I can modify the code to get the LED blinking if you want).

Please let me know how your investigations go.

Best regards,

Adrien.

Adrien,

I apologize, I have been very busy lately and traveling for business. I think I will get another chance to work on this early next week.

If I provide you with a simple working example with PWMs being owned by CPU2, would you be able to compare that with your code to see what could be causing your problem? 

Best Regards,

Ben Collier

Hi Ben,

I can try to compare and let you know how it goes.

Best regards,

Adrien