TMS570LS20216 does not match the target endianness

We tried the same programmer with a different board and it turns out it was the board.  

Nick,

Which board are you using with your XDS200? Is it a TI or custom board?

The TMS570LS20216 is big endian part. Can you double check in your project properties if the check box for Little Endian is unchecked (under Build->ARM Compiler->Processor Option.

Please let me know.

Hi

Thanks for the reply. I work with Nick (he is sitting next to me as I write this). 

We are using a custom board.

On the processor options page the Little endian option is greyed out and says to see the general page. On the general page the device endianness is set to "be32".

So we tried another board at first it worked and then it started to return the same endian error again. We were programming the board from two different computers. It might have started to show the error when we switched computers.

Would any setting that affects the error we are seeing be saved in the Hercules or programmer that prevents further programming. Power cycling the board/programmer does not seem to help.

Thanks

David,

What version of the emupack do you have on each machine?

There is an issue w. the latest update that could cause the endian to flip if you've already loaded in an application that has any sort of exception enabled, and then you try to re-flash.  Described here:

http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/350161.aspx

with some workarounds.    I would try changing the 'Pseudo' setting first in the XML file for the LS20216 and see if that helps...

Also if it doesn't help from Uniflash - try connecting with CCS and seeing if you can control the device.  Then erase the flash if you can through CCS.   After that you can try uniflash again.

How do we issue a system reset only?

Nick,

First, I'm going to assume you had a chance to read the post I linked to in the previous reply so I won't repeat that information here - but if you haven't this might not make sense...

Today when you debug one of the Hercules products in CCS there are two different reset types listed in the Menu Run->Reset.   There is a "CPU Reset" and a "System Reset".

Without changing the Pseudo attribute you need to issue both resets by selecting each of these menu items one at a time, in order to put the device in a known state.   However the CPU reset isn't correct and the system Reset doesn't reset the CPU.

When you change the Pseudo attribute in the device XML per the previous post, the Menu item Run->Reset->System Reset will issue a hardware reset (equivalent to the nRST warm reset button) to the part and it will reset both the CPU and the system logic (all the peripherals, etc...).    You will then no longer need to even use the CPU reset from the menu,  just selecting the System Reset will handle both.

Since the CPU reset menu item also has an issue currently with the way it sets the EE bit in the SCLTR register - you avoid this potential problem by not issuing it.

When I go to run->reset it says "None Available"? Any idea how to get the reset options to show?

It seems as though we cannot get the reset options without being in debug mode, and we cannot get into debug mode without being able to program?

David,

In the "Debug" pane of CCS you have to have the emulator selected (XDS100v2) in order to issue the system reset or CPU reset.  If you just select the top node in the tree you will see no reset available.

Yes you have to have a debug session active.  If you start the debug session by doing "Debug As" then yes you need to program unless you've turned this off (I believe it's an option somewhere) but the easiest way around this is to do View->Target Configurations, select your CCXML file in the target configurations tab, and right click to do a 'Launch .."

When I press system reset I do not see any popup boxes or other action in CCS, is that expected?

Also when I try to look at registers they all say "Error: unable to read"

Also where is the .gel file that we should update (from the link you gave before)?

I am not sure if it matters but we are using a USB200 JTAG Emulator from Blackhawk.

Is it possible to downgrade to a previous version of CCS?

David Kohanbash said:

When I press system reset I do not see any popup boxes or other action in CCS, is that expected?

You should see the program counter go to 0x0000000 at very least.  Depending on what registers you have dispayed you may see many of them reset.

David Kohanbash said:

Also when I try to look at registers they all say "Error: unable to read"

David Kohanbash said:

Also where is the .gel file that we should update (from the link you gave before)?

You can open your target configuration and look at the advanced view to confirm that the value of the Psuedo attribute is not checked.  see picture:

David Kohanbash said:

I am not sure if it matters but we are using a USB200 JTAG Emulator from Blackhawk.

Hi

So after these problems we deleted CCS from the computer and re-installed CCS from scratch and started with a new Hercules processor. It has TI Emulators 5.1.450.0

We now see that error about endianess happen intermittently. It seems like power cycling the Hercules is clearing those errors now. This Hercules has never been programmed with version 5.1.507.x of CCS

Any ideas why we still see this?

David,

To be clear,  emulation pack 5.1.507.x doesn't do anything permanently bad when programming your part.  it's just that if you issue a CPU reset and then try to debug your program,  it corrupts a register and it's a register that a) will flip the endian to little endian on exception entry and b) it's a register that CCS doesn't clear by default.  So this corruption 'sticks' until you do something in hardware to reset it.

Power cycling clears this state because it causes the CPU to be reset in hardware.  

Now, the emulation pack isn't the only way that you might have the Endian bit in the CPSR register flipped.  You can write to it explicitly (this is a feature) and so you might be inadvertently corrupting it with either some stack operation where the stack is corrupted (you might pop the SPSR register onto the stack and later restore it to CPSR, and while the value is on the stack it could be corrupted).

Or you might be just writing to the CPSR incorrectly for example when you are modifying the interrupt enable bits.

To start with - maybe you should search for all instances of CPSR in your code base and see if any of them are in code that might be corrupting the value of the CPSR E bit.     After that check the SCTLR register where the EE bit is set.  These might not be called "SCTLR" though they could be referenced by the long set of coprocessor numbers that you'll find in the CPU technical reference manual.    I wish we could 'break' on a value written to CPSR but unfortunately I don't believe that is possible...

This does sound like a difficult problem to find so focus on any assembly code or any compiler code full of intrinsics.   

And back to the stack overflow potential cause - you should probably explore whether that's a possibility as well.
That's harder to find but you can start by trying to increase the various stack sizes if you still have room in RAM ...

Every TMS570LS20216 that we have programmed with 5.5.507 has been unprogrammable afterwards (even after power cycling). Using earlier versions of the emulator does not help after the fact.

There are no instances of CPSR or SCTLR in the user generated portion of our code.  If they are anywhere in the code, halcogen put them there.

Nick,

If that's the case I'd probably look for any possible stack overflows.

Are you using any sort of RTOS?

Another thing I just remembered - we have this thread in the works and being analyzed

http://e2e.ti.com/support/microcontrollers/hercules/f/312/p/354588/1245179.aspx#1245179

There do seem to be some subtle differences for the 20216 in the CCS based flashing and in the way the older utility nowFlash worked.  So if you suspect it is just related to flash programming you could try nowFlash.
We no longer support nowFlash as it has been replaced by Uniflash, but CCS&Uniflash use the same underlying code so if there is a problem in CCS I wouldn't expect anything different w. Uniflash.  But nowFlash might be worth trying.

Regarding the question you had about CCS and downgrades - from a technical standpoint you can have different CCS versions installed simultaneously.   If you are asking from a license perspective - I don't know and would ask that you check/post that question to the CCS forum.    In any case since evaluation versions are available you could certainly try an older version out if you want to .. and then we can work through the licensing questions only if it actually makes a difference.

EDIT: also I'm running out of ideas of what this might be and so you might want to talk over whether it's feasible for you to send one of these problem boards to us to evaluate. 

2nd EDIT:  I posted nowFlash's installer in the thread mentioned above - since it's no longer distributed on the web.  You can get to it for about 30 days from that link.

We are not running any RTOS.  We can send a board.  Where should we send it to?

Nick

Hi Nick,

You can send it to:

Texas Instruments Inc.

13905 University Blvd

MS102

Sugar Land, TX, 77479

ATTN: Anthony Seely

Please make sure the ATTN is on the label or our shipping department won't know what to do w. the package.

You should receive the board tomorrow.

Hi Nick,

Board arrived and I've unpacked it.   Seems like you have put wires on for +12V power - and I just need to connect this to a +12v supply - is that right?

After that - what is the state of the flash on the board - is it already programed w. the 'problem' code or will I need to program that code in first to create the problem.  (I use 'problem' here loosely - because the real problem might be in the flash programming utility not your code - but what I mean is whether I should already have problems with it or if I need to put something into the part before I can reproduce what you are seeing.)

Thanks and Best Regards,

Anthony

BTW this looks like a great little kit -- is it for sale or is it only for use at your university?

The wires are for power.  The 12V bus is connected to voltage regulators so it will work with 6-12V.  The problem program is on the chip.  The JTAG header is the standard TI JTAG header.

The board is for our Lunar XPrize rover.  It is the second revision.  The preout connector is for the communication signals before the transceivers.  it can go to a switch board to switch IO between processors.  The board also contains transceivers for testing.

We now have a theory that it is this program.

1004.jakeboardelmotest.rar

Nick,

There is something in the code that is in the part that changes the endian.

I just connected an XDS100v2 to the part to halt it wherever it got to by itself and I can see the "E" bit in the CPSR is set to 0.   Issue a system reset and it goes to 1 (big endian) which is right, but then running the code it goes to '0' again. 

Will see if I can figure out what is causing the flip...

Made a quick screen capture so you can see this firsthand:

3365.capture-1.mp4

We don't have an XDS100.  We only have an XDS200.  

We connected the XDS200, launched a configuration for a previously working program.  Then connected to the device.  Then did a system reset and the E bit was still 0 afterwards.  

Also, it says no symbols are defined for 0x00000010.  Your debug window said no symbols defined for 0x00000000.

Nick,

Symbols are included in the .out file, so if you don't load a .out file (which I avoided, because I didn't want to flash the part) you get that message.  If you want to see the symbols you can load symbols only from the .out file but it's not necessary to see that the part flips the endian bit.

I don't have an XDS200 - I could borrow one but I tried an XDS100 first and can reproduce the problem.

If you do a system reset and you still see the E bit set to 0 then I think you have the Pseudo box checked in the emulation driver.  If not you might have an old driver, or it could be something quirky with the XDS200.  Please confirm whether you have Psuedo checked or not.   If you have it unchecked - then I'll get an XDS200 later and see if it acts differently than the other emulators.

At the moment I just connected  a faster emulator (XDS560v2 PRO) and am going to see if I can find code on the part that is flipping CPSR ...

-Anthony

Sorry, I forgot to uncheck pseudo.  It resets the E bit now on system reset, but it still will not program with the same error after the E bit is set to 1.  

Nick,

Ok that could be just a case of the program running enough to flip the E bit before the programming tool can capture the CPU.   Can you ERASE flash?

I had to switch emulators again the 560v2 pro didn't connect but I think that's a problem w. the v2 pro setup files - it is a new emulator for us.   Got a 560v2 STM connected though so will debug now.

Where is the erase option?

I tried going to on-chip-flash and clicking erase flash and I get this error.

Nick,

Just to verify - the rar file that you sent me has the sources and the .out corresponding to what is in the board that you FEDEX'd correct?

What I'm seeing is that as the device init occurs the flash appears to be returning different values every time it's read - so I think the E bit flipping might just be a weird side effect of running 'junk' although maybe it's more predictable than that when the part just runs from reset compared to debugging it.

So what I'd check next is whether something went wrong in the init. 

What jumps out at me - the HalCoGen file that you sent is configured for an 8MHz XTAL input, but the frequency of the XTAL on the board you sent me is 16MHz.  This would throw a lot of the timings off including the flash wait states and it probably would explain a lot.

If nothing else that needs to be fixed before debugging further.

Are you in a position where you can erase the part at?   If so what I'd suggest is:

  - erase your boards

  - adjust the input clock freq. in HalCoGen to 16MHz and if you still want the PLL output at 70MHz adjust the dividers so you get 70MHz at the output...

 - regenerate / rebuild / flash & test

That might wind up being all you need to do but if there is more we can pick up from there.

Nick just saw your answer about the problem erasing - I think our messages crossed..

I don't see any sort of reset pushbutton on your board.   When you tried erasing did you try to do this from after a system reset but before loading any code?  (Did you do it from CCS or Uniflash?)  In CCS the option to erase is a 'hidden' you could say.  To erase from CCS you need to launch your debugger, connect to the part, then select Tools->On Chip Flash.    Scroll down to almost the bottom of this pane and you'll find a button 'Erase Flash'

If those things fail you can try going to this post:

http://e2e.ti.com/support/microcontrollers/hercules/f/312/p/354588/1245179.aspx#1245179

And finding the link (in Box) to the installer for the nowFlash tool that was used before Uniflash.  It might be capable enough to get through this.

I don't want to do any sort of testing myself till I get the answer on the .out file though (whether it's matching what is in the part - a 'verify' succeded for me but better to hear it from you...)  If you tell me it is then I'll try erasing too.  Want to make sure though I can get back into this state.

After a system reset, we pressed erase flash and it gave the error box in the previous post.  

The clock must have been changed in a git merge.  The previous version had an 8MHz crystal and was causing problems with timing.

The nowflash link in your earlier thread does not work anymore.

We think the program I sent you is the one causing the problems.  This morning I programmed another board 8 times with a program and then twice with another and it worked fine.  Then I programmed the one I sent you and it worked the first time, but was bricked when I tried to program it again.

Nick,

Sorry - the expiration date I set is overridden and the link had expired.  I just refreshed it.  Pls. try it again: https://txn.box.com/nfl342r3temp

The XDS200 is not listed as an emulator option in nowflash. Is there something else we can try?

Nick,

Do you have any other TI emulators to try?   I didn't think about that  -- the XDS200 is newer.

If you don't then we'll need to see if we can't get erase to work from CCS. 

From what I gather at this point you would concur that there's nothing to lose if I try to erase the board you sent me?

There is nothing to lose from erasing it.  We don't have any other emulators at this time.  We have someone removing a hercules chip from a hercules launchpad to try to make an XDS100.

Nick,

I get the same error as you do when I try to erase flash with an XDS200 and an XDS560v2 emulator and my XDS100v2 no longer even connects (not sure why it reports a broken scan chain but the other emulators don't...

But I also get the same message just trying to perform a blank check.

I don't get this error with a TMS570LS20216 USB Stick with it's onboard emulator.  Unfortunately no straightforward way to connect one of the other emulators to this usb stick. 

I need to make some inquiries as to what may be making the XDS200 and 560v2 STM come back with that error message about the part not supporting flash.  That could just be something we screwed up in an XML file.

I'm not sure you will be able to do what you want with the RM42 launchpad.  The 14 pin JTAG on the launchpad (RM42) isn't really designed to be an 'output' - it's an input.  There are some subtle differences between the input and output side of the JTAG that can cause problems.  For example the emulator (output) has a pull up on one pin that the target (launchpad) has grounded and this is used for cable unplug detection.  That's probably ok as you'd get a false positive.  But the power detect might present a problem.   And I'm not sure if your TCK/RTCK connection would be right - would need to trace that out.   You might want to hold off and/or purchase an XDS100v2 standalone rather than hack into the launchpad.

We just ordered two XDS100v2. They should be here tomorrow morning. We will try to erase the flash with those.  

Thanks for your continued help!

Hi Nick,

I'm in the meantime trying to understand how the flash programming tools figure out if flash is supported. I think it is by matching some ID information in one or more areas of the part but don't know for sure - just shot an email to the people that would know and we'll hopefully find out tomorrow.

One area I think it was looking at was reading flaky data (data changed every time you refreshed) in code composer I think probably due to the wait states being set wrong (wait states based on 70Mhz when really running at 140MHz).  Since the emulator route is questionable - what do you think about changing the crystal to 8MHz temporarily and seeing if that change allows you to at least get control of the part and erase it again.

Is that something you can easily try?

We have managed to unbrick 3 boards.

The first board, we restarted the computer and clicked debug without selecting any program and it allowed us to erase.

The second board, we tried that and it would not allow us to erase so we stopped it, connected to target, and it allowed us to erase.

The third board would not allow programming.  I connected the target and it would not allow me to erase.  I stepped through assembly till it got stuck with the E bit still set to 1 and then right clicked in the debug window and clicked relaunch and it then allowed me to erase it.

We cannot really find a pattern.

Nick,

That's great... you got a lot further than I did.  Was this with the XDS200 emulator?  Or did you have to use one of the XDS100v2's?

Let me know where you stand now in terms of next steps - Do you still have a backlog of boards to unbrick or are you pretty much done now erasing them?   I talked to one of my colleagues who has done a lot of work with customer returns and he said one trick he's used is to just short out the OSC which should kick in the Osc fail and put the part in a mode where it runs off of the internal osc.  Not sure if that trick will work w. the particular part that you have but you could try that if you've got a backlog of boards.

I think what may make this not so 'repeatable' is that when you try reading from the flash with the frequencies set wrong (and not enough wait states) the flash returns seemingly random values and they are different each time you read them.   The device settings that tell the programming tool which chip they're talking to and what algorithm to use are stored in the OTP sector of the flash and when the part is acting up that also reads incorrectly and seemingly randomly - which I think throws off the tool and makes it think you are not talking to a  flash device.

It's not really surprising that stepping through the code isn't repeatable either because if the flash is returning almost random values this means every time you execute you're actually running a different program.

To make this unbricking repeatable I think we need some trick to keep the frequency from getting to high so the flash returns valid data (even the OTP sector which operates w. the programming tool behind the scenes).  This is where momentarily killing the oscillator might come in and make it repeatable.

If you got through all your backlog though and have unbricked all the boards that you have bricked then I suppose the above is probably irrelevant - and the next step would be to confirm that changing the HalCoGen settings to use a 16MHz input clock is actually the fix needed.

Let me know where you stand and if you need help w. next steps.

We have unbricked all of the assembled boards.

We did not get a chance to use the XDS100 before we unbricked them.

Do you have any idea why the wrong oscillator setting or the E bit unset would prevent us from erasing the flash?  I understand why it could prevent us from loading a program, but I would not have thought it would prevent them from being erased.

I will try changing the clock frequency and seeing if it still bricks a board.

Nick,

just had one email exchange w. one of the developers and he said that the device ID is read on connect.  which would mean that we always connect when the part has run some code and by then it's setup memory such that its' not readable, hence the device ID problem - hence no erase capability.  

There might be an easy workaround to this - but let me try it before suggesting.

Best Regards,

-Anthony

Nick,

This procedure is 'repeatable' - although I haven't figured out how to fully automate it.  I tested it with XDS200.

The key is that when the debug session first launches it will read the device ID from address 0xFFFFFFF0.

This need to read as 0x80206D0D or the flash tools will think it doesn't have flash.

The "E" bit being swapped causes this location to read 0x0D6D2080 instead and that in turn causes the error about not having flash.

So far the cleanest way I have to do this is a mix of scripting and GUI.  [missing piece is I haven't seen how to terminate and relaunch a debug session through the scripting console].

Ok so here would be the steps:

1. Launch your target config file (.ccxml).  Do this through the "Target Configurations" window to avoid loading your program.
2. Connect to the target
3. In the Scripting Console Window issue:
   
   1. halt
   2. eval('GEL_AdvancedReset("System Reset");')
   3. eval('GEL_MemoryFill(0x08000000, 0, 0x0100, 0xEAFFFFFE, 0x13);')
   4. eval('PC=0x08000000')
   5. run
   6. disconnect (may be skipped probably but I didn't try it that way)
4. In the GUI, Terminate the Debug session then relaunch it.

If all goes well you will find the PC stuck in a loop at 0x08000000 which is what those 0xEAFFFFFE opcodes are, and you'll find that the E bit is still 0 EDIT: Oops I meant still '1'.  This relaunching would have made the flash tool fetch the device ID again, and this time it would have fetched the correct value.

There are some other fixes that might be simpler which were proposed but there are some things blocking them that I need to find out and they even may need a CCS update.  But as far as I can tell the above is something you should be able to do now.

By the way when I flashed your .out file again the problem did repeat, even after erasing.

Last - I should say that the first time I did this it didn't fully erase.  but as you can tell on the other thread we are having some issues with erasing on 20216 with ECC turned on.  Haven't checked if you have ECC on, and it may not even matter if the array is reading junk.   But at least from what I saw I got through the erase in 2 passes and that happened only one time out of maybe three or 4 trials.

So if you do get partially erased just kick off another erase and it'll eventually fully erase.

Wow, this is a really elegant solution.