CCS/RM57L843: Unable to erase Flash (Error 242 and 1170)

Hello Merlin,

Sorry you are having some trouble. Have you double checked your configuration file to make sure it is setup for the RM57? Also, have you tried programming with the Uniflash tool (as another reference point since they should use similar methodologies)?

Finally, are you using one of TIs development boards or a custom board?

Costum Board

I couldn't find a repository or documentation for the config files. Can you give me a link?

We have ordered a launchpad board to check the config files.

Thank you for the quick reply

Hello Merlin,

The Target configuration files are included with CCS and should be installed with it if you have selected the support files for Safety MCU or Hercules MCU.

Essentially, when you setup you project, you will select the device and associated target configuration.

For more detailed steps for setting up your CCS project and the target configuration, you can reference the one day training that walks through this setup in an older CCS version. Even though the material is dated by the CCS version, it should still apply to the newer version. The one day training materials can be found on this wiki page: processors.wiki.ti.com/.../Category:TMS570

Thank you for the reply!

We checked and created a new project as described. 

Update:

We can modify registers. 

When trying to write in the memory using the Fill command we get following weird results:

We filled 0x1000 bytes starting with 0x08000000 with 0xAFFE.

In the following 2 screenshots you can see that we can't access all memory bytes. After each power they change.

In the following you can see that the writable blocks are always 64bit long

Hello Merlin,

Can you provide more details regarding the 'fill' command that you are using? I am not familiar with any functionality regarding a 'FILL' command in the debugger?

You also mention some limitation of writing memory after each power change? What type of power change do you refer to? Are you meaning a power cycle of the board/MCU? This would be expected since the memory range you are righting to is volatile memory (SRAM) and is not maintained through power cycles.

Do you have an out file you have tried to program or to enter the debug mode for? i.e., if you have a project that has compiled and built successfully, you can then enter debug and the out file will be programmed into the device. From there you will be able to control execution in debug mode.

Chuck Davenport said:

Can you provide more details regarding the 'fill' command that you are using? I am not familiar with any functionality regarding a 'FILL' command in the debugger?

In CCS I can connect to the MCU by launching the Target Config. After that I can lock at the memory using the Memory Browser. When I right click in the MB I can select a memory fill command.

Chuck Davenport said:

You also mention some limitation of writing memory after each power change? What type of power change do you refer to? Are you meaning a power cycle of the board/MCU? This would be expected since the memory range you are righting to is volatile memory (SRAM) and is not maintained through power cycles.

Power Cycling by turning of the power of the board.

The unexpexted part is that the accessible blocks of the memory change after every power cycle.

Chuck Davenport said:

Do you have an out file you have tried to program or to enter the debug mode for? i.e., if you have a project that has compiled and built successfully, you can then enter debug and the out file will be programmed into the device. From there you will be able to control execution in debug mode.

We have a basic program. But we don't get to the point of writing the program to the MCU. We get the error messages above and CCS leaves the debug mode. Trying a blank check or erasing the flash causes CCS7 to crash.

Uniflash fails with the same error message. 

Is there a document on using an external Clock. The Datasheet offers no Information more than it is supposed to toggle 3.3V.

Can you provide mode details on what you are looking for? i.e., are you considering an external clock for use with the DCC? in place of the crystal? as a source for the RTI? I would need the additional details to answer.

I have an external Clock connected to OSCIN that toggles between 0 and 3.3 V at 16Mhz with a 40/60 duty cycle.

Yellow: Clock at OSCIN

We measured the Jtag signal between debug probe ans MCU and found that the TDO would break down on several ocassions.

We got following measurements

Yellow: TDO
Blue: TCLK

We checked the VCC on the suspicious place:

            TDO Breakdown  <-> TDO normal

Blue:TMS
Yellow: VCC

We searched for the reason and found out that the TMS was the cause for TDO breakdown 

The following showa that:

Blue: TDO
Yellow: TMS
Pink: TCLK or RTCK

TDO is 3-stated at certain times during the scan - at first glance this appears normal.

(this is to allow TDO from several devices on the board to be tied together - only the selected device drives out)

You are right, we looked at the signals of the launchpad reference board and got similar results:

Any ideas what else could be causing our issue?

Merlin,

With respect to your clock source connected to OSCIN, you state that the output of this source has a duty cycle of 60/40. The limits identified in table 6-12 Timing Requirements for Main Oscillator should be considered. Note that I don't believe this has any bearing on the issue at hand but it should be assured that the minimium and maximum pulse widths are being met.

To summarize where we are so far:

With respect to your JTAG circuit, I don't really see any issues and didn't expect to considering you are able to establish a connection to the device and read/browse memory and registers.

The curious part is that when you use the fill command/selection, you are only able to write part of the RAM. Do you know if there is code running in the device already or not? i.e., is this a blank device or could there be some resident MPU related settings or SW that is overwriting part of the memory content that you write to it?

The error message is indicating it cannot connect to the DAP, the operations of reading/writing the registers and filling memory, even partially, all use the DAP so it would seem this is only an issue when trying to initiate a normal debug session, Correct?

When you examine your target configuration, it should something like this picture but, obviously, with the RM57 device instead of the TMS570LC device.

can you confirm this configuration in your target config file? You should also be able to click on target connection and see a successful result of the test.

Chuck Davenport said:

The curious part is that when you use the fill command/selection, you are only able to write part of the RAM. Do you know if there is code running in the device already or not? i.e., is this a blank device or could there be some resident MPU related settings or SW that is overwriting part of the memory content that you write to it?

Yes, I can 'manually' connect to the Icepick, DAP and CortexR5 through launch Target Configuration-> and then manually connecting to each target.

The MCU are blank devices. We were not able to get code on it yet.

Chuck Davenport said:

The error message is indicating it cannot connect to the DAP, the operations of reading/writing the registers and filling memory, even partially, all use the DAP so it would seem this is only an issue when trying to initiate a normal debug session, Correct?

Yes!

The target config file looks like this just with xds100v2 in the top and RM57 like you said.

Chuck Davenport said:

can you confirm this configuration in your target config file? You should also be able to click on target connection and see a successful result of the test.

[Start: Texas Instruments XDS100v2 USB Debug Probe_0]

 Execute the command:
%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

[Result]

-----[Print the board config pathname(s)]------------------------------------

C:\Users\mnagel\AppData\Local\TEXASI~1\CCS\

    ti\0\0\BrdDat\testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

 This utility has selected a 100- or 510-class product.
This utility will load the adapter 'jioserdesusb.dll'.
The library build date was 'May 23 2017'.
The library build time was '19:37:36'.
The library package version is '6.0.628.3'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '4' (0x00000004).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller.
This utility has successfully reset the controller.

-----[Print the reset-command hardware log-file]-----------------------------

The scan-path will be reset by toggling the JTAG TRST signal.
The controller is the FTDI FT2232 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for FTDI FT2232 features.
The controller cannot monitor the value on the EMU[0] pin.
The controller cannot monitor the value on the EMU[1] pin.
The controller cannot control the timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '0' (0x0000). 

-----[The log-file for the JTAG TCLK output generated from the PLL]----------

 There is no hardware for programming the JTAG TCLK frequency.

 -----[Measure the source and frequency of the final JTAG TCLKR input]--------

 There is no hardware for measuring the JTAG TCLK frequency.

 -----[Perform the standard path-length test on the JTAG IR and DR]-----------

 This path-length test uses blocks of 64 32-bit words.
The test for the JTAG IR instruction path-length succeeded.
The JTAG IR instruction path-length is 6 bits.

The test for the JTAG DR bypass path-length succeeded.
The JTAG DR bypass path-length is 1 bits.

-----[Perform the Integrity scan-test on the JTAG IR]------------------------

This test will use blocks of 64 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.

The JTAG IR Integrity scan-test has succeeded. 

-----[Perform the Integrity scan-test on the JTAG DR]------------------------

This test will use blocks of 64 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0

All of the values were scanned correctly.

The JTAG DR Integrity scan-test has succeeded.

 [End: Texas Instruments XDS100v2 USB Debug Probe_0]

Hello Merlin,

Are there any pull-up or pull-down resistors/capacitors on TMS, TDO, nTRST on your own PCB board?

Hello Mr Wang,

I have followed your advise from another thread and got following set up.

I tested the boards with the pull ups, without connecting the RTCK with the same results.

I found that when erasing the memory with uniflash we are able to use the Fill command in CCS7.

I attached the register export before and after the treatment with uniflash

6011.register_after_powering_board.txt

0181.register_after_uniflash.txt

2260.register_without_uniflash_after_error_242.txt

I should add:
We tested 100kHz and 10 kHz connections with the same results
We checked our xds100v2 with a launchpad with no problems

Hello Merlin,

Doesn't your debugger have the RTCK signal? If not, can you connect TCK to RTCK on your board, then try again?

I have 3 Boards, 2 have it connected, the third is in the original state. 

All three have the exact same behavior.

1. Is there a way of shipping a board to Freising for analysis?

2. From your experience: Does it make any difference if I use the xds100v2 or a xds110?

3. Can the ADC and the connected signals cause this issue?

4. I'm measuring a LOW on DCAN4RXD instead of a high I'm getting on all other DCAN lines.

Could this be a simptom?

I will send you the full schematic by PN as I can't publish ist publicly.

Merlin,

Thanks for following up with the online thread to close it out and post your root cause. It is very much appreciated and will hope help others experiencing the same type of issue.