Tiva reset problem

blinky2.zip

I forget blinky2 program.

you get this

Hello Hiroyasu,

Pardon me but I am not still clear what the issue is?

Regards
Amit

Hi,Amit

Thank you for your reply.
The issue is that the device sometimes stops in stand-alone.

Can you see my blinky2 program and keep running in stand-alone with EK-TM4C1294X?

This program repeat soft reset. but Device sometimes stop.
You can check using the LED.

I think this problem need to half our.

Best Regards
Hrioyasu

Hello Hiroyasu,

I don't have a board handy with me. However there are a couple of observations.

1. The delay loop after LED switching ON is small. Can you increase it to something observable visually
2. The delay after enabling the clock for GPIO N may not be sufficient. If you can increase the same to a loop of 10 then does the issue occur
3. When the board does get stuck, did you try to connect CCS debugger w/o code download to see where the CPU is stuck.

Regards
Amit

blinky3.zip

Hi,Amit

I improved my code you said as blinky3.

and I try connnect without download when board get stuck.
PC is 0xF0406808.
Datasheet says this area is reserved area.

Best regards
Hiroyasu

Hello Hiroyasu,

Can you see with the following code... I should be able to try the same tomorrow.

main(void)
{
volatile uint32_t ui32Loop;

for(ui32Loop = 0; ui32Loop < 1000; ui32Loop++)
{
}

SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
SYSCTL_OSC_MAIN |
SYSCTL_USE_PLL |
SYSCTL_CFG_VCO_480), 120000000);

//
// Enable the GPIO port that is used for the on-board LED.
//
SYSCTL_RCGCGPIO_R = SYSCTL_RCGCGPIO_R12;
for(ui32Loop = 0; ui32Loop < 10; ui32Loop++)
{
}

//
// Enable the GPIO pin for the LED (PN0). Set the direction as output, and
// enable the GPIO pin for digital function.
//
GPIO_PORTN_DIR_R = 0x01;
GPIO_PORTN_DEN_R = 0x01;

//
// Turn on the LED.
//
GPIO_PORTN_DATA_R |= 0x01;

for(ui32Loop = 0; ui32Loop < 1000; ui32Loop++)
{
}

SysCtlReset();
}


Regards
Amit

blinky4_from_Amit.zip

Hi,Amit

Thank you for your code.

I try your code as blinky4_from_Amit.

But unfortuately device get stack too.
I try connect after this
PC is 0x46C0BD1C.
Datasheet says this area is reserved area too.

I don't know why.

Regards
Hiroyasu

Hello Hiroyasu,

Will have an update for you tomorrow.

Regards
Amit

Hi,Amit

O.K.Thank you.
I wait for your reply tomorrow.
Please check same thing.

Regards
Hiroyasu

Hello Hiroyasu,

I looked at the issue today and it seems that the CPU is faulting due to MOSC falling oscillations causing a false start up of the PLL and subsequent Fault. I switched it to the Internal Oscillator of 16MHz with 120MHz as PLL clock and it works fine.

Regards
Amit

Amit Ashara said:

I looked at the issue today and it seems that the CPU is faulting due to MOSC falling oscillations causing a false start up of the PLL and subsequent Fault. I switched it to the Internal Oscillator of 16MHz with 120MHz as PLL clock and it works fine.

Does this a there is a hardware problem with the MOSC, or with how the TivaWare SysCtlClockFreqSet() function configures the MOSC?

I wonder if the cause of the problem in this thread is the same as described in TM4C129ENCPDT locks up, using ethernet, and a soft reset. In both cases the reported failure occurs after a number of resets, and both are using:

    SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ | SYSCTL_OSC_MAIN | SYSCTL_USE_PLL | SYSCTL_CFG_VCO_480), 120000000);

Hello Chester,

It may very well be the same issue. I also tried a large delay loop and have to get the scope plot for the Main Oscillator done w.r.t the startup issue.

Regards
Amit

Hi,Amit

I wanna know about MOSC hard issue or Tivaware SysCtlClockFreqSet() issue.
Actually We need to use MOSC.
Can you tell me how to use we should deal with this issue ?

Regards
Hiroyasu

Hello Hiroyasu,

The issue seems to be the decay time of the Crystal oscillations. If the Crystal is enabled during the decay time of the oscillations, the PLL will be unstable as well for some time before the Crystal stabilizes. During this time the wrong CPU frequency could land the device into a fault.

The solution is to add a large delay before the SysCtlClockFreqSet to ensure the Crystal Oscillations have decayed completely for a correct start. Now how large (see the post by Chester on a similar issue).

Regards
Amit

Amit Ashara said:

CPU is faulting due to MOSC falling oscillations causing a false start up of the PLL and subsequent Fault

Hi Amit,

Pardon - but is not, "Switch-over to internal oscillator" a "Band-Aid" at best - a poor "solution" at worst?

For many decades MCUs have been able to employ external xtals & oscillators - especially when stable (and known) frequency is required.

As we read here -- this appears to be a serious problem - and one which has not (really) been resolved...

Hello cb1,

I agree. But the issue still needs additional debug with a scope since the failure is not on the first reset but takes time. Also for TM4C123 the Power Up time of the oscillators was accounted during clock enable function which is not there in TM4C129 (and I need to identify why it was not done).

Regards
Amit

The solution is to add a large delay before the SysCtlClockFreqSet to ensure the Crystal Oscillations have decayed completely for a correct start. Now how large (see the post by Chester on a similar issue).

Hi,Amit

Can you tell me how long we need delay before the SysCtlClockFreqSet().
I could not understand after I read Chester's thread.
I think that thread talked about "after" the SysCtlClockFreqSet().

Actually I try 10000 count delay before SysCtlClockFreqSet() like this.

  for(ui32Loop = 0; ui32Loop < 10000; ui32Loop++)
  {
  }

  SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
  SYSCTL_OSC_MAIN |
  SYSCTL_USE_PLL |
  SYSCTL_CFG_VCO_480), 120000000);

It still get stuck.

Regards
Hiroyasu

Hello Hiroyasu,

I would need to ascertain the delay and/or condition correctly first, test the same and update the forum post.

Regards
Amit

Hi,Amit

O.K.
We are in a hurry.
Please update as soon as possble.
Thank you.

Regards
Hiroyasu

Hello Hiroyasu,

I have a fix now for the issue. It requires recompiling the driverlib as the sysctl.c has to be changed. I have been testing with the fix for abouta day now and the code seems to be holding. The line to change is 2187 in sysctl.c

replace
ui32OscSelect = SYSCTL_RSCLKCFG_OSCSRC_MOSC;

with
ui32OscSelect = SYSCTL_RSCLKCFG_OSCSRC_PIOSC;

recompile the driverlib.lib and then recompile the main blinky project after changing the path to the new driverlib.lib

Regards
Amit

Amit Ashara said:

The line to change is 2187 in sysctl.c

replace
ui32OscSelect = SYSCTL_RSCLKCFG_OSCSRC_MOSC;

with
 ui32OscSelect = SYSCTL_RSCLKCFG_OSCSRC_PIOSC;

Am I correct in that the reason for the change is to make the Oscillator Source the internal PIOSC, rather than the external MOSC, during the time the PLL is locking to the external MOSC?

Is the same issue as errata MEM#09 on ROM_SysCtlClockFreqSet(), or a different issue?

[The workaround for MEM#09 says to use the TivaWare SysCtlClockFreqSet() function in flash memory]

Hello Chester,

Yes, that is correct. I am ensuring that the OSC Clock Source remains as the PIOSC during and after the PLL Lock. This allows on reset the PIOSC to still clock the core reset mechanism w/o being gated on the MOSC clock to be cut off abruptly. What is interesting is the issue is suspected during the earlier PLL Lock which causes an effect on the next boot. The actual root cause is getting determined as the test is unpredictable in its failure rate.

No it is not the same issue as MEM#09.

Regards
Amit

Amit Ashara said:

What is interesting is the issue is suspected during the earlier PLL Lock which causes an effect on the next boot.

I have attached the debugger after the failure, and the processor was in the FaultISR. The "Bus Fault Address Register Valid", "Stack Bus Fault" and "Precise Data Bus Error" bits were set in the NVIC_FAULT_STAT register. The NVIC_FAULT_ADDR register pointed at an address in the __TI_auto_init start-up function, so agree that the failure appears to occur on the next boot.

As well as seeing the failure using the flash based SysCtlClockFreqSet() from TivaWare 2.1.0.12573, I also saw the failure using the ROM based ROM_SysCtlClockFreqSet() call in a XM4C1294NCPDT revision 2 part. i.e. the ROM based ROM_SysCtlClockFreqSet() may need the same correction as the TivaWare SysCtlClockFreqSet().

For reference I looked at the changes to the clock related registers after the the following [ROM_]SysCtlClockFreqSet call:

    freq = SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
                               SYSCTL_OSC_MAIN |
                               SYSCTL_USE_PLL |
                               SYSCTL_CFG_VCO_480), 120000000);

1) Using SysCtlClockFreqSet() from an unmodified TivaWare 2.1.0.12573:

2) Using SysCtlClockFreqSet() from a the TivaWare 2.1.0.12573 syctl.c modified as per the previous suggestion in this thread:

From the modification can see that the SYS_RSCLKCFG_OSCSRC has been set to 0 (PIOSC) rather than 3 (MOSC) which sets the Oscillator Source when the PLL is bypassed.

3) Using ROM_SysCtlClockFreqSet in a  XM4C1294NCPDT revision 2 part:

Where the  ROM_SysCtlClockFreqSet has set the same SYSCTL_RSCLKCFG value as the SysCtlClockFreqSet() from an unmodified TivaWare 2.1.0.12573

Hello Chester,

Yes. If the issue arises from the manner in which the OSCSRC is changed to MOSC even though PLLSRC is used for system clock then a change is required to the ROM function as well. But that has to wait for the issue to be well understood first.

Regards
Amit

Hi, Amit

Thank you for your reply.
I try to recompile driverlib after replace code.

but I still get stuck.

I've tried in this program

blinky4_from_Amit2.zip

Have you change anything except driverlib?

Regards
Hiroyasu

Hello Hiroyasu,

I think I added the define TARGET_IS_TM4C129_RA1

I have been running the code that you sent and updated the SysCtlClockFreqSet only for the addition of the line. It hasn't failed so far. Can you check in debug mode that after the SysCtlClockFreqSet function is completed the value of SYSCTL_RSCLKCFG register is 0x13000003?

EDIT: Attached is my sysctl.c that you can compare with your copy of sysctl.c

sysctl.c

Regards
Amit

Hi,Amit

I added the define TARGET_IS_TM4C129_RA1.
I recompile driverlib(sysctl.c) you gave me.
and I made sure SYSCTL_RSCLKCFG register is 0x13000003 after SysCtlClockFreqSet().

but I get stuck on 2 EVM.

Do you use device rev3 ?

Reagards
Hiroyasu

Hello Hiroyasu,

Yes, I have a rev3 device. Can you send in the updated CCS project.

Regards
Amit

Hello Amit, Preliminary testing looks promising with this fix. I am going to continue to do longer term testing, but in the meantime can you tell me if TI will be including this problem in the errata, and an updated Tivaware library will be released in the future?

Thanks,
Cam

Hi, Amit

Please make sure my project.

blinky4_from_Amit3.zip

Thank you.

Regards

Hiroyasu

Hello Hiroyasu,

We started another silicon for testing and so far after the WA we could not reproduce the issue. Also what we notices is the ARM Compiler/Liner version that you are using is 5.0.11 and we are using 5.2.0 and 5.1.1. With our versions of the toolchain (we could not change the tool chain version to yours as the older installation is not there in CCSv5 and v6) the issue does not occur, but by loading your bin file we could still see the issue. There could be subtelties of the tool chain version as well. Can you update the toolchain on your side so that all of us are baselined (please do keep 5.0.11 since the WA is not holding on that version of the tool chain).

Regards
Amit

Hi,Amit

I update ARM Compiler v5.2.0 on CCSv6.0.1.00040.
and I build with driverlib and Project.
but it still got stuck.

blinky4_from_Amit4.zip

Can you send me your project you make ?

Regards
Hiroyasu

Hello Hiroyasu,

Thank you for doing so. Attached is the project. Please note that I compile driverlib as a separate project and use the blink project property to link the new driverlib from CCS workspace.

0601.blinky4_from_Amit2.zip

Regards

Amit

Hi,Amit

Thank you for your project.
I download out file you sent without build.

I get stuck with 2 EVM again.

Can you test again with another EVM?

Regards
Hiroyasu

Hello Hiroyasu,

The project bin was built with MOSC as Run Time Oscillator Clock Source. The attached project with the WA code does not fail.

8662.blinky4_from_Amit2.zip

Unfortunately I do not have enough EVM's to spare considering there are other example codes being tested. But we do understand that there is an issue that needs to be debugged, so rest assured we will try to assist you and other users to get to the Root Cause at the earliest

Regards

Amit

Hi,Amit

I get stuck with project you sent again.
Can you give me your driverlib.lib ?

Thank you.

Regards
Hiroyasu

Hello Hiroyasu

Attached are the driverlib for the Pass and Fail case

Pass:

driverlib.lib

Fail:

driverlib_fail.lib

Regards

Amit

Amit Ashara said:

Attached are the driverlib for the Pass and Fail case

 Hi Amit, just a two cent suggestion, what about send two new devkit to customer and pick up the two failing to give a case study on?

Hi, Amit

Thank you for sending driverlib.

I test again.
Both driverlib.lib and driverlib_fail.lib get stuck.
How much time did you test with your pass project(driverlib.lib)?

Actually I think it makes no difference.
Our Project and EVM include device revision are same.
I can not understand why situation is different.
What do you think about this situation??

Regards
Hiroyasu

Hello Hiroyasu

The Pass case was running over the weekend. I am not sure if we are seeing an outlier to the WA. It would be good if you can send the failing parts back to TI for analysis.

Regards
Amit

Hi, Amit

O.K. I will send TI for analysis.Thank you.

and Can you tell me your board Revision ?
I use Rev D.

Regards
Hiroyasu

Hello Hiroyasu,

I am using an internal test board with the latest silicon revision also, so it is not a board artifact.

Regards
Amit

Hi, Amit

O.K. Thank you.

Regards
Hiroyasu

Amit Ashara said:

I have a fix now for the issue. It requires recompiling the driverlib as the sysctl.c has to be changed. I have been testing with the fix for abouta day now and the code seems to be holding. The line to change is 2187 in sysctl.c

replace
ui32OscSelect = SYSCTL_RSCLKCFG_OSCSRC_MOSC;

with
ui32OscSelect = SYSCTL_RSCLKCFG_OSCSRC_PIOSC;

When looking at a tirtos_tivac_2_01_00_03 TI-RTOS project for a TM4C1294NCPDT, noticed that TI-RTOS has a Boot_sysCtlClockFreqSetI function in products\bios_6_40_03_39\packages\ti\catalog\arm\cortexm4\tiva\ce\Boot_sysctl.c which has the same logic as the SysCtlClockFreqSet function from TivaWare.

Therefore, assuming that the suggested change to the TivaWare SysCtlClockFreqSet function is the correct fix for this problem, should the TI-RTOS Boot_sysCtlClockFreqSetI function also be changed?

Hello Chester

Yes, it would need to be changed as well.

Regards
Amit

Hello 

We have a project with TM4c1294 processor. 

Ocasionally the system does not startup after a reset. After a week of debugging, we found that the system stops in the EMACPHYConfigSet routine. In this situation, the debugger can't connect to the ARM anymore.

I understand there are other people with this problem, also see this thread.

But I didn't understand what actually has to be done to fix it. Can you please help us?

Regards,
Daniel

Hello Daniel

Before I can suggest anything, I would like to know which TivaWare version are you using?

Hi Amit
Thanks for your answer.
We are using 2.1.0.12573. I have replaced the sysctl module with the one from 2.1.3.156, but that didn't help.
Currently I try if disabling the flash prefetch helps.

Regards,
Daniel

Hello Daniel

What about the driverlib.lib. Did you replace that as well?

Hi Amit
No, we don't use driverlib.lib. We build the whole software out of source files.

At the moment it looks like disabling the flash prefetching helps. But we need to test further.
Would you expect that to help in this problem?

Regards,
Daniel