• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 55 subscribers
  • Views 729 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.

CCS/LAUNCHXL-F28377S: Memory Browser Refresh Un-blocks The Program in Debug

Galen Church
Prodigy 170 points
Part Number: LAUNCHXL-F28377S


Tool/software: Code Composer Studio

I am debugging some software on my c2000 and I have encountered an issue that seems to be resolved when I used the "Memory Browser" in CCS7 to refresh/read of an area of memory.  It doesn't seem to be particular to a specific memory location but once I refresh it it unblocks my code (and in continuous refresh it runs perfectly)

My program involves some less then straight forward hand-shaking that I handle in the SPI ISR and I believe the root issue lies within there (My best guess is there is a interrupt flag I am not clearing at the correct time).  With the number of flags the SPI has, and the fact many of my debugging circumstances cause the code to work fine, I am curious if anyone has any insight into exactly what the memory browser refresh does, e.g. is it halting some ISRs from being handled/clearing certain flags with the SPI and its FIFO in particular?  For reference I am using the built-in JTAG emulator with the LAUNCHXL-F28377S: the XDS100v2.

Any help would be appreciated.

-Galen

  • 0
    Guru 92251 points

    Galen Church said:
    It doesn't seem to be particular to a specific memory location but once I refresh it it unblocks my code (and in continuous refresh it runs perfectly)

    When the memory browser unblocks your program were you attempting to step the program?

    The reason for asking is that by default CCS disables interrupts when assembler stepping or source stepping which can cause the program to hang if say attempt to step-over a function call which waits for an interrupt.

    See Program/Memory Load Options for the options to control when CCS disables interrupts.

  • 0 in reply to Chester Gillon
    Prodigy 170 points

    Thanks for the response and pointing me towards the Debug Handbook (that looks to be a very useful resource).  I was not stepping but it made me think that the issue must be with interrupt flags in my SPI ISR...

    I seemed to have it working now: as part of my handshaking between two devices there is an instance where I expect the SPIx_RX_ISR to be called due to the RXFFINT but do not care to read the value in the buffer, SPIRXBUF, all I do is return a GPIO STE line low.  I am using this state solely for transmitting so to clear the interrupt flag I was just simply setting RXFFINTCLR.  Setting RXFFINTCLR was not actually clearing the RXFFINT flag, but I was able to work around that by adding a dummy read of the SPIRXBUF, which clears the flag reliably.

    I don't know that this matches my interpretation of the SPI interrupt's operation from the datasheets when I have FIFO enabled, but it works.