• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 482 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.

Startup Code for TMS570LS20x

Mark Blay
Intellectual 370 points
Other Parts Discussed in Thread: HALCOGEN, TMS570LS3137

Hi,

Is the sample code that was originally published with spna106 still available?

I noticed on another thread that the code had been removed as the initialisation steps it demonstrated had now been incorporated into Halcogen. However for TMS570LS20x code generation for LBIST which I am currently working on is not supported in the tool and I am not able to find any other sample code.

Many thanks,

Mark. 

  • 0
    TI__Guru 59540 points

    Hello Mark,

    I apologize for the delay in getting back to you; however, you could use Halcogen to generate the same code by selecting the LS3137 device. The code associated with the application note spna106 was generated in this way. Note that this code is for these later devices so it can be used as reference but will not necessarily be 100% executable on our device. Specifically for the LBIST section, please make sure the STCCLK configuration and number of intervals are compatible with the device you are working with.

  • 0 in reply to Chuck Davenport
    Intellectual 370 points

    Hi Chuck,

    I tried as you suggested and unfortunately in the version of Halcogen that I have (v3.06.00) the LBIST module is also grayed out for TMS570LS3137 micro so I have the same problem that I am not able to generate example code.

    Is there another processor choice that is close enough to TMS570LS20x that I could use to obtain some sample code?

    Thanks,

    Mark.

  • 0 in reply to Mark Blay
    TI__Guru 59540 points

    Hello Mark,

    Which version of Halcogen are you using? Once I know this I can look to see which devices it supports and try and make a suggestion of one that you can use.

    In the mean time, I took the liberty of generating the safety init startup for the LS3137 using Halcogen v3.06. The generated code is attached.

     2146.LS3137 Startup Code from Halcogen v3.06.zip

    Note that since this code is for the LS3137, there may be some code/features that are not compatible to the LS20x and I as I mentioned previously, there may be differences in the STC code due to some changes from one device to the next. I would suggest reviewing the code and perhaps the datasheets to identify these differences before proceeding.

  • 0 in reply to Chuck Davenport
    Intellectual 370 points

    Hi Chuck, thank you very much, the generated code looks like it has most of what I need to get a good understanding of the range of startup checks.

    I am using Halcogen v3.06 also so I'm not sure why I was not seeing the option to configure LBIST with LS3137 as target. I have not used the tool too much so I guess there is probably some configuration I am missing.

    I will take a more thorough look over the code in the next few days, but for now thank you again for your help.

    Mark.

  • 0 in reply to Mark Blay
    TI__Guru 59540 points

    Great to hear Mark!

    If you are satisfied with the solution on this thread please mark the answer verified so that we can close it. If questions come up later you can open a new thread with any new questions that come from your implementation process.

  • 0 in reply to Chuck Davenport
    Intellectual 370 points

    Hi Chuck,

    I have a couple of questions relating to the initialisation code.

    1) The TRM recommends that backup of registers is performed prior to executing LBIST (and STC self check) in order to restore system state after reset. The example code appears to take a simpler approach and simply repeat all steps prior to test execution and make running of the tests conditional on the reason for reset and self test status. With this approach there is no need to store system state and apart from the small overhead of running a small amount of initialisation code twice there appears to be no disadvantage. Is there any other reason why backing up system status would be a preferable approach?

    2) When is it recommended to configure the peripherals used by the application? Halcogen generates the functions such as spiInit() but does not include calls to these functions. The reason for the question is that the TRM recommends writing to CPSR prior to the call to main() such that the application is executed in user mode (which is not done in the generated code as far as I can see). My initial thought was that peripheral initialisation would be specific to the application and would therefore be part of application software, i.e. called after the call to main(). However some bits in the peripheral control registers have R/WP permission and so would not be writeable if the switch to user mode had been made. Can you advise what the recommended approach to peripheral initialisation is?

    Thanks,

    Mark.  

  • 0 in reply to Mark Blay
    TI__Guru 59540 points

    Mark Blay said:

    Hi Chuck,

    I have a couple of questions relating to the initialisation code.

    1) The TRM recommends that backup of registers is performed prior to executing LBIST (and STC self check) in order to restore system state after reset. The example code appears to take a simpler approach and simply repeat all steps prior to test execution and make running of the tests conditional on the reason for reset and self test status. With this approach there is no need to store system state and apart from the small overhead of running a small amount of initialisation code twice there appears to be no disadvantage. Is there any other reason why backing up system status would be a preferable approach?

    CD==> LBIST is designed to be ran either at startup or cyclically. If running at start up and you can afford the time to re-initialize the CPU registers, then doing the context save is not required. If running  after critical initialization that can't be re-ran or in a cyclical manner within the application, then context save and restore would be required.

    2) When is it recommended to configure the peripherals used by the application? Halcogen generates the functions such as spiInit() but does not include calls to these functions. The reason for the question is that the TRM recommends writing to CPSR prior to the call to main() such that the application is executed in user mode (which is not done in the generated code as far as I can see). My initial thought was that peripheral initialisation would be specific to the application and would therefore be part of application software, i.e. called after the call to main(). However some bits in the peripheral control registers have R/WP permission and so would not be writeable if the switch to user mode had been made. Can you advise what the recommended approach to peripheral initialisation is?

    CD==> This is at the discretion of the application. As you mentioned, some peripheral registers are protected and you need to be in a privelege mode to modify them. Itwould be required to switch from user to privelege mode before performing the init on these registers which could be handled through a function call that abstracts this task out. Generally speaking, I usually see the init functions called in the startup code prior to entering main because it can get a bit messy going in and out of privelege modes within the application and also there is the opportunity that a developer forgets to disable it after enabling it for a specific protected write.

    Thanks,

    Mark.