• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 32 subscribers
  • Views 1005 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.

TRACE Capabillities using the TMS5701114BPGE or ZWTQ

Robert Pettersson
Prodigy 40 points
Other Parts Discussed in Thread: TMS570LC4357

 I am planning to use the TMS5701114BPGE/ZWTQ in a safety-critical application and needs to carry out real-time tracing/code coverage metrics in order to comply with the standards.

 I cannot find any information regarding the possibillitiy to carry out a real-time trace on the TMS5701114BPGE, it seems not to be available even in the BGA-package (ZWTQ). How is this done, considering the TMS570 is aimed at the safety-critical market where this kind of feature is absolutely necessary ?

 On the super-set parts, the TMS570LS2x/3x/4x, tracing seems to be around (for the BGA-versions) but these lacks the peripherals called ePWM (enhanced PWM) and eQEP (enhanced Quadrature Encoder) which I need in order to develop a motor-control application. Are these parts not intended for motor-control ?

Anyone out there with some experience that may be able to help me out ?

 Thanks!

  • 0
    TI__Expert 4580 points

    Hello:

    We have received your post and we will get back to you soon.

    Regards.

  • 0
    TI__Guru 68920 points

    Robert.

    Your assessment of the family is correct.  The LS3137 is intended as the trace & calibration superset for the TMS570 series but it does not have the ePWM, eQEP, and eCAP peripherals.

    Two options for you within the hercules series - if you need to trace at the same time you have timer device drivers running:

      1) stick w. the LS1xxx series and use the N2HET(s) instead of the ePWM, eQEP, eCAP peripherals.   This means learning to use the N2HET (development cost) but your end device could still be the LS1xxx.  You would use the LS3137 as the superset emulation device in this case.

     2) Use the new Cortex R5 based TMS570LC4357 or RM58L843 parts - these have both trace and the e* Peripherals. They are cached cortex R5 parts so they are not proper supersets of the LS1xxx, and they are more expensive mainly due to the much larger on chip flash and ram, as well as the much higher CPU frequency - but this may be the lowesr development cost solution for your use case if the per unit cost isn't as critical.

  • 0 in reply to Anthony F. Seely
    Prodigy 40 points

    Thanks Anthony for a very good answer.

     IF I then would use the N2HET it will then be a question, from a safety-critical point of view, how do I debug the code in the N2HET during development, and second, how do I do my code-coverage-checking on the assembler code actually inside the N2HET ?

     I really do like the e* peripherals very much and would hate to see them go. In the reference-manual (sections 6.5) for the TMS570LS1x series it mentions something about a RAM trace-port (RTP). Could this be used (without instrumentation of my code) for trace/code-coverage ?

     If the RTP needs instrumentation of my code in order to work, what tool could then provide me with such features ?

     What (third-party) HW would need to be used to access the RTP ?

     Since the application is very time-critical I cannot stop the processor to upload some trace-information, neither is it allowed for the instrumentation (of the embedded code) to affect the timing of the code (in a major way, that is).

     And last but not least, where may I find code-examples of N2HET-code implementing center-aligned PWM (no deadband) and qudrature encoder input decoding ?

  • 0 in reply to Robert Pettersson
    TI__Guru 68920 points

    Hi Robert,

    Sorry for the delay on the reply, just catching up on the forum and trying to get initial responses done.  Now looking through some of the older posts.

    Robert Pettersson said:
    IF I then would use the N2HET it will then be a question, from a safety-critical point of view, how do I debug the code in the N2HET during development, and second, how do I do my code-coverage-checking on the assembler code actually inside the N2HET ?

    I think the options are:

       - Use the HET IDE simulator.  It has a waveform viewer that is powerful and upgradeable (SynaptiCAD).
         I can check with them to see if they have any way to interrogate waveforms for transitions.

       - Manual or scripted use of breakpoints which can be inserted in every instruction of the HET code.

    The normal strategy for HET is to use one HET to check another though.

    Robert Pettersson said:
     I really do like the e* peripherals very much and would hate to see them go.

    Yes they are not going, they're actually 'coming' unfortunately we made the LS3137 before we started including these peripherals in the family but they have been on every new silicon since the LS3137.   The new LS4357 does include both ETM and a large number of e* peripherals.

    Robert Pettersson said:
    In the reference-manual (sections 6.5) for the TMS570LS1x series it mentions something about a RAM trace-port (RTP). Could this be used (without instrumentation of my code) for trace/code-coverage ?

     

    Yes.  TI doesn't have a tool that supports RTP / DMM but there is at least 1 third party (Vector Informatik) that does.  Their purpose is for a task called calibration in the automotive market.  I didn't think that the LS1xx series had RTP/DMM though - if you see that it does somewhere please point me to this so I can run that down.

    Robert Pettersson said:
     If the RTP needs instrumentation of my code in order to work, what tool could then provide me with such features ?

    I have an idea on this and will contact you more directly.  Our software team has been working with one vendor and we've started discussing how to extend their tool to cover ETM.  What I'm thinking with the LS1xxx series (off the cuff) is that for pratical purposes writing to an external memory location (on EMIF) which could be attached to a 'dual port' RAM style mailbox that is monitored by another MCU could be just as good for the LS1xxx series as an RTP port.  Or at least almost just as good.  

    Robert Pettersson said:
     What (third-party) HW would need to be used to access the RTP ?

      I think it's the VX1000 but there may be some other box or pod that is needed in addition.   Another option is that supposedly RTP/DMM are analogous to each other so you can hook up two devices  RTP->DMM and DMM->RTP.    

    Robert Pettersson said:
    Since the application is very time-critical I cannot stop the processor to upload some trace-information, neither is it allowed for the instrumentation (of the embedded code) to affect the timing of the code (in a major way, that is).

       ETM doesn't stop the processor at all necessarily - it can work in such a way for debug but for what you're talking about the ETM capture can run independently of the CPU stopping/starting and the ETM buffer can be stopped when it is full, uploaded, and then restarted all without affecting the state of the CPU.  You will have gaps in the trace data when this is done but hopefully with enough samples you'd fill in the gaps.

    An EMIF write might take 30-40 cycles but the CPU has a write buffer and can therefore fire/forget.  So I think the impact of using an external memory mailbox as a logger of sorts might also be feasible.   What do you think about this approach.

    Robert Pettersson said:
     And last but not least, where may I find code-examples of N2HET-code implementing center-aligned PWM (no deadband) and qudrature encoder input decoding ?

    I think the most mature example het program we have includes deadband and complementary pairs, and we can work on reducing this (should be easy compared to building it up in the first place ;).   Also there is a good example of QEP on this post this forum post.