• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 29 subscribers
  • Views 742 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.

TMS570LS0432 flash FMSTAT .. Reserved bit#11 showing 1

Eric Brundick
Guru 12956 points
Other Parts Discussed in Thread: RM42L432

Hi folks-

I am experimenting with the JTAG interface on the Hercules LaunchPad, trying to implement a flasher application outside of TI's own tools.

I've been running into a roadblock where any sector erase operations fail; what's bizarre is the FMSTAT register shows values such as 0x00000c10 or 0x00000810.  The former value has "EV" set, Erase Verify, along with CSTAT=1, so I suppose that is explanation enough (seems to happen with sectors #0 and #1 of the main flash).  But the latter only shows CSTAT=1 and bit #11, labeled "Reserved" in the TRM, as set to 1, and according to the TRM this bit#11 should always read as 0.  The TRM does mention that sometimes a flash error will set CSTAT but if the cause is outside the scope of the register's explanatory bits, it will be the only indication.

What I'm wondering, is this bit#11 a secret bit that might explain the cause/reason for my sector erase errors?

Haven't found anything in the errata yet that could explain this.

Quick link- TRM http://www.ti.com/lit/ug/spnu517a/spnu517a.pdf

Product page- http://www.ti.com/product/tms570ls0432

For what it's worth, the LaunchPad does have a TMX570LS0432 onboard.

  • 0
    Guru 12956 points

    Nevermind, think I found this one out, or at least got further than before.

    I was writing full 32-bit words to FSM_COMMAND and FSM_EXECUTE, when the "Advanced F021 Flash API" document mentions (in the pseudocode examples of how to implement the erase & program flow) that only the intended bits of those registers should be written.  Narrowing down my writes to the lower 8-bits only when writing them, I get a successful (or at least FMSTAT=0x00000000) flash erase done.

  • 0
    TI__Genius 9015 points

    Hello Eric,

    bit #11 is not a secret per se, but something you should never see occur.  It has to do with preconditioning done during erase.  All FSM errors will set the CSTAT bit.

    The only way I have ever seen the type of problems you are getting is from the FMC not being correctly initialized.  If you could post your project, I can take a look at it and see if I can spot the problem.

  • 0 in reply to John Hall
    Guru 12956 points

    Thanks John... I'm betting that's it since I haven't done much preinit stuff yet.  As it turns out I didn't figure out the problem, but was confused as to the endianness of the registers... it appeared my 8-bit write wasn't actually triggering execution, now that it is the behavior is back to the original example.  I'll get the init stuff written properly before continuing.  There is an app note on that I believe (http://www.ti.com/lit/an/spna163/spna163.pdf)

  • 0 in reply to Eric Brundick
    TI__Genius 9015 points

    That app note is for initializing the device.  To initialize the flash you need to call Fapi_initializeFlashBanks() and Fapi_setActiveFlashBank() functions before using the erase, program or read/verify functions in the API.

  • 0 in reply to John Hall
    Guru 12956 points

    John-

    After doing some more searching and finding other posts by you regarding the F021 library, it appears my original intent behind this project is flawed and I will revise.

    My original intention was to implement flashing capability for the TMS570LS04 & RM42L432 into OpenOCD, an open-source JTAG debugging suite.  This required writing a new flash driver library for the software that works with the Hercules' flash controller.  Unfortunately it looks like the critical initialization pieces--pump voltage setting, etc. isn't documented in the TRM and is locked into the F021 API.

    So the next best thing would be to write a bootloader using the F021 API and see if OpenOCD can just dump it into RAM every time I wish to reflash the chip.  It could communicate over SCI or maybe even JTAG itself and provide a way to use the TI library for flashing while being capable of flashing the chip from other O/S's such as Linux and MacOSX.

    My next question is- What kind of restrictions are there for distributing the F021 library's binaries?  The idea would be to build a bootloader ELF file and distribute that with the tool.  But if that's not possible for legal reasons, then I'd need the user to d/l F021 libraries and build the project separately on Windows.  Either way could work IMO.

  • 0 in reply to Eric Brundick
    TI__Genius 9015 points

    Eric,

    I will need to check with legal on that.  I think the governing clause in the clickwrap license agreement on this subject is:

    e.     Restrictions.  You shall not use the Licensed Materials with a processing device other than a TI Device, and you agree that any such unauthorized use of the Licensed Materials is a material breach of this Agreement.  You shall not use the Licensed Materials for the purpose of analyzing or proving infringement of any of your patents by either TI or TI’s customers.  Except as expressly provided in this Agreement, you shall not copy, publish, disclose, display, provide, transfer or make available the Licensed Materials to any third party and you shall not sublicense, transfer, or assign the Licensed Materials or your rights under this Agreement to any third party.  You shall not mortgage, pledge or encumber the Licensed Materials in any way.  You may use the Licensed Materials with Open Source Software or with software developed using Open Source Software tools provided you do not incorporate, combine or distribute the Licensed Materials in a manner that subjects the Licensed Materials to any license obligations or any other intellectual property related terms of any license governing such Open Source Software. "Open Source Software" means any software licensed under terms requiring that (A) the software provided under this Agreement (“Proprietary Software”) incorporated, combined or distributed with such software or developed using such software: (i) be disclosed or distributed in source code form; or (ii) otherwise be licensed on terms inconsistent with the terms of this Agreement, including but not limited to permitting use of the Proprietary Software on or with devices other than TI Devices, or (B) require the owner of Proprietary Software to license any of its patents to users of the Open Source Software and/or Proprietary Software incorporated, combined or distributed with such Open Source Software or developed using such Open Source Software.  

  • 0 in reply to John Hall
    Guru 12956 points

    Yeah, sounds like this'll have to be "built by the end-user".  Thanks for your help!

  • 0 in reply to Eric Brundick
    TI__Genius 9015 points

    Eric,

    Legal's opinion matches your conclusion that it will have to be "built by the end-user".