• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 898 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.

HalcoGen 04.05.00 prefetch problem

Henrik Danielsson
Expert 1405 points
Other Parts Discussed in Thread: HALCOGEN, TMS570LS0432

I have three diffrent boards. Each has it's HalCoGen project and it has been running ok when generated with HalCoGewn version 04.04.00. I just installed 04.05.00 and generated code for one of my boards. and then it hits the prefetch vector 0xc with LR register = 0xA5A5A5A8. Strange I thought and tested my other projects and it's the same, it also hits the prefetch vector. 

Any body else having problem with HalCoGen 04.05.00. I'm running a TMS570LS0432 FreeRTOS project on the IAR tool chain.

I've seached this forum and the closest I've found was a thread called"Prefetch Abort Interrupt using IAR", solved by fixing "LR register was off".I don't understand, what did he do to "turn LR register on", is it somewhere in HalCoGen? 

I've stripped down my code to a minimum with only one task running and it's the same. It tends to happen during a vTaskDelay I've notised, but not always. 

As said my code did work before HalCoGen 04.05.00, could it be a problem in my code or maybe anybody else having the same problem?

Any tips on how to debug this?

  • 0
    Expert 1405 points
    After reverting "os_portasm.asm" to a previous version (generated by HalCoGen 04.04.00) my code is running again. I guess this file is specific to the IAR compiler? I'm running the IAR 7.40.3 (the latest). Registers R0 and R11 are used differently. This is just a guess, but maybe I need to tell my compiler not to use specific registers (like the R11 register)? I don't have the knowledge of debugging the changes made to "os_portasm.asm", maybe the HalCoGen team will look into this?
  • 0 in reply to Henrik Danielsson
    TI__Guru 65600 points

    Henrik,

    Assume you mean this post:   ..

    I don't know what is meant precisely by LR is off but I think it doesnt' mean OFF/ON  but rather 'pointing OFF of the address where it should have been pointing'.

    LR is a register that is automatically used by the CPU whenver there is a branch or an exception - to hold the return address.  

    It gets put onto the stack quite a lot ... for example if you make nested function calls, the caller needs to save LR to the stack before calling a subroutine.    Also the LR register is banked - meaning there are different LR registers for each CPU mode.

    So you can corrupt LR by:   stack corruption (or restoring LR from an empty / uninitialized stack),  switching modes and using the wrong 'lr', etc.    I think it was probably one of these things that put LR off target.

    I ran a comparison of port.asm from the freertos driver folder, and I can see what you mean where the SWI handler now pushes R11 onto the stack and restores it on exit, where it didn't do this before.

    But to me that looks like it's done because later in the specific SWI # functions, like Disable Interrupts, R11 is used as a working register instead of R0.   Not so much that a specific tool-chain dependent issue is at play.

    It could be possible that doing this introduced a bug though...

     

    If you have a test case that fails and can send this to us - we'll look at it and see if there's some underlying issue that was introduced w. this change. 

    Thanks and Best Regards,

    Anthony

     

  • 0 in reply to Anthony F. Seely
    TI__Mastermind 31525 points

    Henrick.

    I created a simple blinky project using HALCoGen v04.05.00 with IAR.  I could not reproduce the issue.

    Attaching the project I used.

    8585.FREERTOS_TMS570LS04x_IAR.zip

    Could you send us the project so that we can check at our side.

    Regards,

    Veena

  • 0 in reply to Veena Kamath
    Expert 1405 points

    Hello

    Thank you for the sample project. As you said it does run ok.

    I have not found the bug, but I know what is causing it. Setting configTIMER_TASK_PRIORITY to 0 will cause code generated by HalCoGen 04.05.00 to hit prefetch. If I change this to "1" code is runing as expected.

    Setting configTIMER_TASK_PRIORITY to 0 is valid, se link:

    http://www.freertos.org/Configuring-a-real-time-RTOS-application-to-use-software-timers.html

    There might be a potential bug in the FreeRTOS port generated by 04.05.00. I now have a workaround (setting configTIMER_TASK_PRIORITY>0). It would be nice find out why configTIMER_TASK_PRIORITY=0 doesn't work.

  • 0 in reply to Henrik Danielsson
    TI__Guru 65600 points
    Hi Henrik,
    Veena sent me a mail saying she found an issue in one of the SWI routines, and suggested a fix:
    swiPortYield ; Restore stack and LR before calling vPortYieldProcessor
    ldmfd sp!, {r12,lr}  should be ldmfd sp!, {r11, r12,lr}
    although probably best that you continue discussing w. Veena as she's got the expertise, but thought I should post the proposed fix so you can try it in the interim.
    Best Regards,Anthony
  • 0 in reply to Anthony F. Seely
    Expert 1405 points

    Hi Anthony and Veena

    I can confirm that it is a good fix. Thank you very much!

    Best Regards

    Henrik

  • 0 in reply to Henrik Danielsson
    Prodigy 230 points

    I reported the exact same issue in the GCC port, although in that case it was a different register getting clobbered by the SVC interrupt handler (reported to be fixed in v4.05, but I haven't verified it yet).   Since this has happend twice now, I suggest that the HALCOGEN team should audit all of their assembly-code ISR's to ensure that they are saving the clobbered registers.