F28M35x processor suddenly jumps to boot code

Hello!

Mitch Hanks said:

Often when I run code my code will execute for a few moments and then execution seems to jump to boot code to an assembly statement 'IDLE' (address 3ff6b7). 

Could you please clarify what code do you load into the C28 core? Is this some example project of controlSUITE or somethig else?

Regards,

Igor

It is not strictly example code but heavily uses functions from the Controlsuite device support library plus code from the High Voltage Sensored FOC example, modified to work on the F28M35x controlCard plugged into the DRV8312EVM. 

Mitch

Still dealing with this problem.  It comes and goes but when it is present it seems to occur at the same time after run from startup.  I can get rid of it for a short time (10-15 minutes) by making modest changes to code and recompiling.  It comes back, however.  

The 'C28 processor on the F28M35 does not appear to have a watchdog function.  Is there another hardware function that could cause a vectoring to boot code? 

Is there a way to capture where it was just before it jumps to this IDLE statement?  

Hello Mitch!

Is there such strange behavior with your code only? Is all right with examples from controlSUITE? Did you try to check?

Regards,

Igor

I've been using the f28069 control card to make progress but have come back to look at this problem again.  I have two F28M35 ControlCards that exhibit the same behavior.  I am seeing the problem on ControlSuite code.  If I run setup_m3 on the M3 processor out of RAM, and adc_soc_c28 on the control processor out of ram,  it runs for a few minutes and then jumps to boot code.  In my own code I cut out virtually everything but a call to InitAdc1().  When I remove that statement, no jump, when I put it back in, it jumps to boot code.  

Can someone at T.I. try this setup - F28M35 ControlCard in DRV8312EVM running the specified code?  Do you see a jump to boot code?  

Mitch

Mitch,

What version of F28M35x device_support are you using from controlSUITE?

Also what revision of F28M35x silicon are you using?  (Revision 0, A or B)


Thank you,
Brett

I do not see a file or identifier called device_support.  What/where is this?

I cannot tell from the markings on the chip and the errata sheet which version it is.  Here are the markings on the chip:

x  980

F28M35H52C1RFPT

YF 16A8HEW

G4

Latest information:

If I reprogram the C28's flash memory with the Flash version of adc_soc_c28 and run out of flash, the jump to boot code does not happen.  Also, when I go back and load the Ram version of adc_soc_c28 and run it, no jump.  When I load my code again and run it, the problem starts happening again.  Something is apparently getting programmed in non-volatile memory that creates this situation and then continues to affect whatever code is running (at least it affects my code, and the controlSuite adc_soc_c28 code)  until it is overwritten.  

I am apparently using 'experimental' parts.  Not sure why that is what I am getting when I purchase an F28M35 ControlCard but that is what I got both times. 

Mitch,

Based on the information you have given you are using sample-grade (experimental) Concerto MCUs.  We only recently moved to production-grade devices so it is very possible that this is what you have on your controlCARDs.  These chips should however be adequate for project creation, etc.

What is the path to the c28x examples that you are running?  This will tell us which version of examples you are using.  For example the below is v200.
\controlSUITE\device_support\f28m35x\v200\F28M35x_examples_Control\adc_soc\c28\

We're looking into the issue.


Thank you,
Brett

Brett,

The adc_soc_c28 example code is v201.  

I don't have a consistent cause and effect relationship tracked down, but did see the following:

When I am seeing the problem regularly (a few seconds into runtime), I can put a while(1) statement a few lines past the start point of my code.  When it is after an InitAdc1() call, I see the jump to boot rom.  When I put the statement before that call, I don't see the problem. That is why I chose to run the controlSuite example code adc_soc_c28 and verified that I would see the problem with that code running.  This is all with code running out of RAM.  When I load adc_soc_c28 into flash and run it, the problem goes away (no jump to boot rom).  When I switch back to RAM with adc_soc_c28, I still don't see the problem (as if writing to Flash memory got rid of whatever my code did).  When I run my code again (out of RAM), it soon starts exhibiting the problem again. 

Thanks for your help,

Mitch

I discovered today that this problem seems related to another problem that I have been seeking help with here:

http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/304468/1061356.aspx#1061356

When the 'jump to boot rom' problem is occurring regularly, I have noticed that my code is running at full speed (as if on a 150MHz system clock).  When I load flash memory with adc_soc_c28 or cpu_timers_c28, the jump to boot rom no longer occurs, but I also notice that my code is executing at half the speed (as if on a 75MHz) clock.  These two seem tightly correlated (failure with full speed, no failure with half speed).  I am always running the same M3 code for these experiments. 

By the way, the code ends up at an IDLE instruction after the jump to boot ROM.

Mitch, 

    I am not sure if this is related, but we recently added a couple new errata that can cause unexpected behavior particularly when configuring the analog subsystem clocks.  It is possible that the workarounds have not made it into the controlSUITE examples yet.  Please try the documented workarounds and see if clears up the behavior at all.

http://www.ti.com/lit/pdf/sprz357

Analog Subsystem: Analog Subsystem Function InitAnalogSystemClock() is Incomplete

Analog Subsystem: Potential Race Condition after Executing Analog Subsystem Functions AnalogClockEnable() or AnalogClockDisable()

regard, Joe

Joe,

I added both fixes to my code but it did not fix the problem.  Thanks for the ideas, however.

Mitch

Hi Brett

Does Mitch have the newst version of the chip? How can we check it?

Otherwise we should try to update to the newest chip revision if you feel that it's a hardware relating problem.

This is a very important problem for our design, so we need to fix it.

Regards

Roland

@Mitch: The effect occurs only when exectuting out of RAM, not when the code is in the flash?

Roland,

I believe the following is true:

1. When the part is first powered and connected to, and I run my code (out of RAM, which is the only way I can run it so far) it appears to execute momentarily at full speed.  I observe execution speed indirectly by watching a signal on my scope which asserts every sample period and I see this operating at full speed. 

2. A few seconds after my code starts to run, my signal goes flat (no more assertions).  When I pause code execution, I see that it is executing an IDLE statement at 0x3ff2b7.  Usually if I pause the M3 code, I will see that it is no longer executing user code either (executing somewhere in 0x2xxxxx).  I can reload my code, rerun, and it very repeatably runs for a few seconds in my code then stops executing my code and I'll see that it is executing at the aforementioned locations. 

3. In this mode of operation, I can load adc_soc_c28 from the ControlSuite into RAM (completely TI code), and after a few seconds of execution, it will also to the above mentioned locations.  If in running my code I insert an infinite loop right before a call to InitAdc1(), the jump does not occur.  If I move the infinite loop right after that call, the jump does occur. 

4. If I load adc_soc_c28 into flash and run it for a few seconds, and then load my code back into RAM (only choice right now) and run it, my code will run indefinitely with no jumps to the above mentioned locations.  HOWEVER, I will observe that the sample rate is running at less than half speed.  The sample rate indicates that the processor is running at 60MHz instead of 150MHz. 

Mitch

Roland,

I don't think the issue is a preproduction vs production MCU issue, but since you will want to move to it once you start producing your end product it may be useful to go ahead and do this anyway.  I will note that we have fixed some previous errata in RevB F28M35x.


Mitch,
What is you clock source and PLL settings?  I forgot to ask this previously: can you confirm the issue on multiple C2000 devices?  Or is this a single chip?


Thank you,
Brett

Hi Brett

How can I order a control card with RevB MCU? Is this organised from your end or does I need to ask our local TI rep?

Regards

Roland

Mitch Hanks said:

Joe,

I added both fixes to my code but it did not fix the problem.  Thanks for the ideas, however.

Mitch