• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 52 subscribers
  • Views 766 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2640: Debugger fails every second run

Ross Arnott
Intellectual 470 points
Part Number: CC2640

Hi,

I'm seeing an issue in debugging where my firmware fails on every second run and ends up in the Hwi_excHandler() function (every second run being pausing execution then restarting).

I can't quite figure why the code ends up causing a HWI exception, but trying to trace it through it does look like something to do with the spi accesses to the external flash failing every second run.  However that doesn't really help me to fix it.

I don't see this with a power cycle, that consistently seems to work.  

Something is clearly not being reset correctly when debugging, but it's not clear to me what.  Any suggestions would be very welcome.  

I thought I had broken something in my code, which is derived from the Sensortag application, but I have tried this on the Sensortag 2 app without modification and I see pretty much the same behaviour - the debugger spins into the Hwi_excHandler function on the second run and so it never starts to advertise.  It then works on the 3rd run, fails on the 4th etc.

Thanks,

Ross

  • 0
    TI__Guru 55895 points
    Hi,

    Can you post what the PC and the value of CPU_SCS is when the exception occurs?

    Are you using custom HW or TI HW?
  • 0 in reply to Christin Lee
    Intellectual 470 points

    Hi,

    Thanks for the reply.  I'm using custom hardware for my application, however as I mentioned I see something very similar on the Sensortag 2 setup.  I had a simpleBLEperipheral project running fine on the custom hardware but decided to make use of more of the sensortag app functionality as I'm interfacing to an IMU chip.

    When the device has hit the Hwi_excHandler function on a 'failing' run I see the following values:

    PC=0x0000D096

    R CPU_SCS_RESERVED000 0x0000000B 0x00000000
    R CPU_SCS_ICTR 0x0000000B 0x00000001
    R CPU_SCS_ACTLR 0x0000000B 0x00000000
    R CPU_SCS_STCSR 0x0000000B 0x00000004
    R CPU_SCS_STRVR 0x0000000B 0x00000000
    R CPU_SCS_STCVR 0x0000000B 0x00000000
    R CPU_SCS_STCR 0x0000000B 0xC0075300
    R CPU_SCS_NVIC_ISER0 0x0000000B 0x10000410
    R CPU_SCS_NVIC_ISER1 0x0000000B 0x00000000
    R CPU_SCS_RESERVED0 0x0000000B 0x00000000
    R CPU_SCS_NVIC_ICER0 0x0000000B 0x10000410
    R CPU_SCS_NVIC_ICER1 0x0000000B 0x00000000
    R CPU_SCS_RESERVED1 0x0000000B 0x00000000
    R CPU_SCS_NVIC_ISPR0 0x0000000B 0x20000010
    R CPU_SCS_NVIC_ISPR1 0x0000000B 0x00000000
    R CPU_SCS_RESERVED2 0x0000000B 0x00000000
    R CPU_SCS_NVIC_ICPR0 0x0000000B 0x20000010
    R CPU_SCS_NVIC_ICPR1 0x0000000B 0x00000000
    R CPU_SCS_RESERVED3 0x0000000B 0x00000000
    R CPU_SCS_NVIC_IABR0 0x0000000B 0x00000000
    R CPU_SCS_NVIC_IABR1 0x0000000B 0x00000000
    R CPU_SCS_RESERVED4 0x0000000B 0x00000000
    R CPU_SCS_NVIC_IPR0 0x0000000B 0x00000000
    R CPU_SCS_NVIC_IPR1 0x0000000B 0x000000E0
    R CPU_SCS_NVIC_IPR2 0x0000000B 0x00E0E000
    R CPU_SCS_NVIC_IPR3 0x0000000B 0x00000000
    R CPU_SCS_NVIC_IPR4 0x0000000B 0x00000000
    R CPU_SCS_NVIC_IPR5 0x0000000B 0x00000000
    R CPU_SCS_NVIC_IPR6 0x0000000B 0x00000000
    R CPU_SCS_NVIC_IPR7 0x0000000B 0x000000E0
    R CPU_SCS_NVIC_IPR8 0x0000000B 0x00000000
    R CPU_SCS_RESERVED5 0x0000000B 0x00000000
    R CPU_SCS_CPUID 0x0000000B 0x412FC231
    R CPU_SCS_ICSR 0x0000000B 0x00414803
    R CPU_SCS_VTOR 0x0000000B 0x20000000
    R CPU_SCS_AIRCR 0x0000000B 0xFA050000
    R CPU_SCS_SCR 0x0000000B 0x00000000
    R CPU_SCS_CCR 0x0000000B 0x00000200
    R CPU_SCS_SHPR1 0x0000000B 0x00000000
    R CPU_SCS_SHPR2 0x0000000B 0x00000000
    R CPU_SCS_SHPR3 0x0000000B 0x00200000
    R CPU_SCS_SHCSR 0x0000000B 0x00000000
    R CPU_SCS_CFSR 0x0000000B 0x00008200
    R CPU_SCS_HFSR 0x0000000B 0x40000000
    R CPU_SCS_DFSR 0x0000000B 0x00000000
    R CPU_SCS_MMFAR 0x0000000B 0x400C8000
    R CPU_SCS_BFAR 0x0000000B 0x400C8000
    R CPU_SCS_AFSR 0x0000000B 0x00000000
    R CPU_SCS_ID_PFR0 0x0000000B 0x00000030
    R CPU_SCS_ID_PFR1 0x0000000B 0x00000200
    R CPU_SCS_ID_DFR0 0x0000000B 0x00100000
    R CPU_SCS_ID_AFR0 0x0000000B 0x00000000
    R CPU_SCS_ID_MMFR0 0x0000000B 0x00100030
    R CPU_SCS_ID_MMFR1 0x0000000B 0x00000000
    R CPU_SCS_ID_MMFR2 0x0000000B 0x01000000
    R CPU_SCS_ID_MMFR3 0x0000000B 0x00000000
    R CPU_SCS_ID_ISAR0 0x0000000B 0x01101110
    R CPU_SCS_ID_ISAR1 0x0000000B 0x02111000
    R CPU_SCS_ID_ISAR2 0x0000000B 0x21112231
    R CPU_SCS_ID_ISAR3 0x0000000B 0x01111110
    R CPU_SCS_ID_ISAR4 0x0000000B 0x01310132
    R CPU_SCS_CPACR 0x0000000B 0x00000000
    R CPU_SCS_RESERVED6 0x0000000B 0x00000000
    R CPU_SCS_DHCSR 0x0000000B 0x00030003
    R CPU_SCS_DCRSR 0x0000000B 0x00000000
    R CPU_SCS_DCRDR 0x0000000B 0x00002001
    R CPU_SCS_DEMCR 0x0000000B 0x01000001
    R CPU_SCS_STIR 0x0000000B 0x00000000

    Thanks,

    Ross

  • 0 in reply to Ross Arnott
    TI__Guru 55895 points
    You can take a look at our software developer's guide section 9.8 and our TRM table 2-132 for more debug information.

    It's a bus fault on your custom HW. The address where the bus fault occurs is 0x400C8000.

    There are a lot more stuff on sensortag app than simple_peripheral. Do you have all the sensors connected as sensortag? Are all the sensor reset properly?
  • 0 in reply to Christin Lee
    Intellectual 470 points

    Hi,

    Thanks for the response.  I have disabled pretty much all of the sensors in this code just now, I only have a BNO070 IMU sensor device on the board and I've also commented that code out for now.  

    As I said before, this is also happening with the Sensortag 2 hardware using the default sensortag firmware project too so I'm not 100% sure it's something I've done.

    I used the ROV to look at the properties of the exception in more detail - see below:

    I don't know what the NOROM_DDI16BitfieldRead process is doing and I can't see what's called it so I am only a little further forward.

    The disassembly view of PC=0x00008C04 is:

    Any suggestions for where to go next with the debug are very welcome.

    Thanks,

    Ross

  • 0 in reply to Ross Arnott
    Intellectual 470 points

    Hi,

    I have managed to resolve this issue.  I won't pretend I fully understand what is going on but I found this article and tried removing the POWER_SAVING predefined symbol as suggested there.  Once that was enamed to xPOWER_SAVING the application runs consistently.  

    What do I lose by turning off POWER_SAVING?  It's not something I'm familiar with.

    I think this is something in the original code.  I looked at the Sensortag 2 debug and it's very similar and can be 'fixed' in the same way.  Some details below in case someone at TI wants to try and log a bug report? 

    Running the same debug on Sensortag 2 and it has the same value in the CFSR register as in my custom hardware and the BFAR address is also 0x400C800.

    Regards,

    Ross

  • 0 in reply to Ross Arnott
    TI__Guru 55895 points
    Hi Ross,

    Thanks for providing the debug information. We will look into this.

    By disabling power saving, the device will never go to standby. That means your battery will be drained fairly quick.
  • 0 in reply to Christin Lee
    Intellectual 470 points

    Hi Christin,

    Thanks.  It would be really good to have this resolved as not being able to put the device into standby is a bit of a disaster for almost any battery powered application.

    Is there somewhere that I can track progress for potential bugs like this?  It won't be long before it causes a problem again.

    Thanks,

    Ross