• Locked Locked
  • Replies 5 replies
  • Subscribers 53 subscribers
  • Views 787 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Strange behaviour on Stellaris trace CCS V5.x

Roberto Romano
Guru 27285 points

Os Version: Linux Ubuntu 10.4 LTE 32 Bit 

Uname -a : 2.6.32-46-generic #108-Ubuntu SMP Thu Apr 11 15:55:01 UTC 2013 i686 GNU/Linux

CCS  Version: 5.4.0.00091

Licence: limited version both MSP and ARM (buy full licence planned later if all processor specific issue (HW, SW and not least availability get solved)

 Trouble is version independent, for now I am using 32BIt OS, I Also installed on my next laptop but on latest 64Bit Ubuntu refuse to start.. (I fix myself later lib dependence)

 I am porting examples from LM3S to get acquainted to LM4/TIVA, this migration is not pain free, I resolved the stack failure but this also suffer a so strange problem I am not able to address from where it come, deterministic execute first time but not the second one identical instruction, problem is repetitive to same assembly instruction forever.

 The driver module code execute right on SdCard example ported to this platform but not this reduced 2555.grlib_demo.zip.

All project is included here, this is from RDMIDK example, I cannot compile full version due to licence limit, after a while I identified where code lost control, assembly step over:

First STEP

Next step crash.. Any idea why???

  • Mastermind 7925 points

    1. Unitialized peripheral

    or more likely

    2. You are building for wrong chip. Check predefines in project properties

    Regards,
    Maciej  

  • in reply to MaciejKucia
    Guru 27285 points

    MaciejKucia said:

    1. Unitialized peripheral

     This case trouble happen on FIRST write not after few writes... Rejected!

    MaciejKucia said:
    2. You are building for wrong chip. Check predefines in project properties

     Everything is correct than some possible strange  obscure settings ... still not found...

     Same code is working, I copied project from working sdcard example I pasted code there and I it work, I realized startup_ccs.c was missing, so I added to that project and now after the second instruction execute I see ISR FAULT is fired... Again why not after first write to?

     SAME CODE is working if pasted in a copy of a working project...

  • in reply to Roberto Romano
    Mastermind 7925 points

    Roberto Romano said:
     This case trouble happen on FIRST write not after few writes... Rejected!

    Unfortunately some devices are going into fault in non-deterministic way therefore you cannot imply like that. Sometimes it will work sometimes will not. Especially during debug.

    I have imported the project you posted and I see some strange things. 

    In predefined symbols I can see only ccs="ccs". Where you define chip and chip class?

    Regards,
    Maciej 

  • Guru 92251 points

    Roberto Romano said:
    All project is included here, this is from RDMIDK example, I cannot compile full version due to licence limit, after a while I identified where code lost control, assembly step over

    The screen shot shows the crash happening on one of the following lines:

    HWREG(LCD_WR_BASE + GPIO_O_DATA + (LCD_WR_PIN << 2)) = 0;
    HWREG(LCD_WR_BASE + GPIO_O_DATA + (LCD_WR_PIN << 2)) = 0;

    The attached project has the CPU set to LM4F120H5QR, and LCD_WR_BASE is defined as:
    #define LCD_WR_BASE GPIO_PORTH_BASE
    The LM4F120H5QR only has 6 GIPO ports GPIOA to GPIOF. Therefore, won't the code fail when it tries to attempt to access the non-existent GPIOH on the  LM4F120H5QR?

  • in reply to MaciejKucia
    Guru 92251 points

     

    MaciejKucia said:

     This case trouble happen on FIRST write not after few writes... Rejected!

    Unfortunately some devices are going into fault in non-deterministic way therefore you cannot imply like that. Sometimes it will work sometimes will not. Especially during debug

    [/quote]From looking at the LM4F120H5QR datasheet by default write buffer usage is enabled within the Cortex-M4. This means that writing to a non-existent, or disabled peripheral, causes an Imprecise Data Bus Error which can allow the processor to continue executing some instructions before the bus error is raised.

    By setting the DISWBUF bit in the Auxiliary Control (ACTLR) write buffer usage within the Cortex-M4 is disabled and all bus faults are precise bus faults which means the faultISR should be entered after the instruction which writes to a non-existent or disabled peripheral, but performance is decreased because any store to memory must complete before the processor can execute the next instruction.