Tiva reset problem

blinky2.zip

I forget blinky2 program.

you get this

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

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

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.

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);

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

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...

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

Amit Ashara said:

The line to change is 2187 in sysctl.c

replace
ui32OscSelect = SYSCTL_RSCLKCFG_OSCSRC_MOSC;

with
 ui32OscSelect = SYSCTL_RSCLKCFG_OSCSRC_PIOSC;

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]

Amit Ashara said:

What is interesting is the issue is suspected during the earlier PLL Lock which causes an effect 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

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

Please make sure my project.

blinky4_from_Amit3.zip

Thank you.

Regards

Hiroyasu

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

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

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

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

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;

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 

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