• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 4 answers
  • Subscribers 82 subscribers
  • Views 1002 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.

CCS/TMS320F28035: F28035 ILLEGAL ISR due to continuos refresh in CCS?

mdhrf
Prodigy 40 points
Part Number: TMS320F28035

Tool/software: Code Composer Studio

Hi,

I observe ILLEGAL ISR (vector 19 0x0000 0D26 2 Illegal Operation) interrupts after a few seconds as soon as I have the "continuous refresh" activated in an "Expressions" or "Memory browser" window in the CCS. The return address pushed by the ISR always is a valid code address. Sometimes it happens that the CPU jumps to a totally wrong address.

This happens both on 28035 control card with docking station (XDS 100v2) and with our own hardware with a TI XDS110, CCS is Version: 7.2.0.00013.

If continuous refresh is off, the application runs minutes and hours without any problem, as far as I can see.

Maybe its worth to mention that the CLA is running too and both CLA and CPU run with high interrupt frequencies (period 3 respectively 9 microseconds). Substantially lower CPU interrupt frequency seems to "help".

Any hint please?

Thanks & regards,

Frank

  • 0
    TI__Guru 55700 points
    Frank,

    Continuous Refresh causes all open memory windows to refresh at the refresh rate.

    When this option is enabled when C28x code is running simultaneously, the same data bus is shared between continuous refresh read and C28x code execution read this given the possibility of data corruption. This can lead to C28x reading an illegal opcode which when executed can lead to triggering illegal ISR.

    Continuous refresh is used for debug option. This option will not affect your system when running standalone without emulator.

    Regards,
    Manoj
  • 0 in reply to Manoj Santha Mohan
    Prodigy 40 points

    Manoj,

    thank you for your answer, but I am very sorry, it does not solve my problem.

    What a "Continuous refresh" is good for if the CPU is not running?

    I would have suggested to rename it to "Continuous refresh until sooner or later the CPU crashes", but I never had this problem with a F28377S.

    So is it a F28035 problem only?

    Regards,

    Frank

  • 0 in reply to mdhrf
    TI__Guru 55700 points

    Frank,

    F28377S is a much faster device (200MHz) vs F28035 (60MHz). So, using continuous refresh can possibly cause data corruption when continuous refresh is used.

    One way to possibly get around this is use polite continuous refresh mode and also reduce the frequency at which continuous refresh is done.

    Enable Polite continuous refresh mode mode by going to CCS menu Run->Debug Configurations->Target  tab

    and also reduce the frequency at which continuous refresh by method shown below.

    For more information,

    http://processors.wiki.ti.com/index.php/CCS_Modules_Library#Real-time_Debug

    Regards,

    Manoj

  • 0 in reply to mdhrf
    TI__Guru* 77460 points
    Frank,
    In CCS under the "Window" menu item, select "Preferences". In the new dialog box select "Debug"(don't expand it, just click on Debug). This will bring up a preferences menu that near the bottom shows the continuous refresh interval. The default is 500ms, can you confirm this is the setting for your CCS? If you try a slower rate, does it help the Illegal ISR happen less often?

    You mention the CLA and CPU are running on the F28035, can you comment on the memory region that you are viewing/that is continously refreshed, i.e. is it the shared CPU/CLA RAM; CLA only, CPU only, etc.

    My understanding of this mode is that it should be pulling data in spare cycles; I suppose its possible if you are at a higher utilization on the F2803x vs the F28377 there may be less free time to do this. I would expect this to impact the refresh rate/abilty, not pass the impact to the CPU in some way to cause a TRAP.

    I'll get some folks from the IDE team to see what they think should or could happen here.

    Best,
    Matthew
  • 0 in reply to MatthewPate
    Prodigy 40 points

    Manoj & Matthew,

    thank you for your help. I tried the Real-Time-Mode as Manoj suggested, seems that this really helps. No Illegal ISRs anymore during my tests so far.

    @Matthew: The refresh rate is the default one (500 ms). Watched variables were both in CPU and CLA space, but most critical seemed to be watching the CLA2CPU message RAM @ 0x1480 (with very frequent access both by CLA and CPU ISRs).

    Thanks & regards,

    Frank

    PS: The F28377 runs (only) 3 1/3 times faster than the F28035 (200 vs. 60 MHz), so if the F28035 crashes statistically after 3 seconds, so c.p. the F28377 should crash after 10 seconds, but it does not...

  • 0 in reply to mdhrf
    TI__Guru* 77460 points
    Frank,
    We had some internal discussions on this, and the real time mode will influence the behaivor of the continous refresh, making sure that "Polite"
    real time is selected(I think it gets highlighted as well on activation of real time). Left alone the continous refresh is in "Rude" Realtime by default and could hold up some ISRs if too intensive.

    We don't have any instance of code corruption per se, so this must be some artifact of the rude vs polite that we are seeing. Let us know if this rears its head again, but I think the above aligns with what you tried based on Manoj's suggestion.

    Best,
    Matthew
  • 0 in reply to MatthewPate
    Prodigy 40 points

    Matthew,

    I read about the real time debug mode etc. (Chapter 7 of SPRU430F and the presentation Manoj suggested) to understand more. But it's still not fully clear to me why the real time / polite mode (yes, it's higlighted too) helps to prevent the Illegal ISRs (no ISR nesting, stack is sane). I'd rather expect corrupted data than a wrong code fetch.

    I made some more tests, and it is really the CLA2CPU MSGRAM @ 0x1480 that is especially sensitive.

    Anyway, the real time / polite mode seems to work reliable.

    Thank you again,

    Frank