RM46L852 Permanent damage

William,

I doubt that your device is damage by a wrong setting on the PLL.

Can you have a look to the following post and try the 2 options mentioned to erase the code from the device.

Please let me know if you need more assistance.

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

Hello Jean-Marc,

I tried using UniFlash to "erase cores" (I didn't see that before).  Anyway, I get these messages:

[15:03:46] Erasing flash sectors on Core 0 < Texas Instruments XDS2xx USB Emulator/CortexR4 > ...
[15:03:46] CortexR4: GEL Output:     Memory Map Setup for Flash @ Address 0x0
[15:03:47] Begin Erase Flash operation.
[15:03:47] Erase operation is not supported on this core.
[15:03:49] Operation Erase Flash returned.

William,

I have to run this experiment on my setup and I will let you know the result.

William,

Also to be in the same condition, which version of UniFlash are you using?

Jean-Marc,

CCS UniFlash

 Version: 3.1.0.00022

 (c) Copyright Texas Instruments, 2014. All rights reserved.

William,

I'm able to erase RM48L852 using the same version of UniFlash.

Now the next step will be for me to program my test device with the same code you are using.

Will it be possible to share your project. If not on the forum, I can send you my direct email address.

Please let me know.

No project necessary.  Just use Hello World, with or without HalCoGen.  Even with this minimal program, the program won't load on my processor.   As I said earlier, it would before I had changed HalCoGen to generate a PLL in excess of 220mhz.

A minor point: I'm using the Spectrum Digial XDS200 USB emulator; the CCS and UniFlash only list this as a TI took (there is no listing for a SD XDS200).  One other point - we use the ARM 10 pin header on our custom board and the SD 20 pin to ARM 10 pin adapter.   With the ARM 10 pin connector, there is no connection for RTCK.  Not sure if this is an issue or not.

William,

If you were able to program and debug in the past with this ARM10/ARM20 configuration, I don't think there is a problem here.

On my side I've generated a basic test code setting the PLL to 330Mhz with Halcogen,
I've programmed this code and I still can connect and disconnect to the target. Of course the code is not working correctly and I end up in exception. At any time I can still take control of the device with the debugger and erase the part.

I will really need the exact step and code that you programmed in the device to end up with this problem.

Without the same environment I'm not sure I can help a lot.

If you want, I can set up a webex and phone call for tomorrow morning. 
just let me know.

Jean-Marc,

If I debug the application, I get the same error message found in this thread:  http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/321992.aspx

"CortexR4: GEL Output: Memory Map Setup for Flash @ Address 0x0CortexR4: Loader: One or more sections of your program falls into a memory region that is not writable. These regions will not actually be written to the target. Check your linker configuration and/or memory map."

I've also seen another forum post where others have seen the same message.

From the interaction of the debugger, it seems that the debugger querys the chip to see what sectors can be written - then the chip replys with it's sector information and the CCS compares that with the linker.cmd file?

I just don't understand how a working chip with no more than a HalCoGen program (no user code), with the default linker.cmd file could cause this error.

Hi William,

I don't have a solution to your issue but maybe I can provide some background on the debug subsystem.  

CCS uses a memory map input by the user to determine which memory regions on the target are writable.  One reason why this is important because setting a breakpoint can be done in two ways by the debugger - by copying a memory location and overwriting with a breakpoint opcode (software breakpoint, effectively unlimited) or by using hardware breakpoint resources (comparators, which are limited).

The CCS message as I understand it can be from a couple of issues.  First (and most likely), there could be a discontinuity between the user input memory map to CCS and the memory region in the linked object code.  Second, depending on settings the debugger will try to read back code it has loaded to confirm the load was carried out properly;if the read-back does not match the write, an error message is triggered.

In your case, I suspect the 2nd case is what has happened.  

Regards,
Karl 

Karl,

Thanks for the info.  I also suspect that the 2nd case is occurring.   Does this mean that the chip is probably bad?

It is doubtful that there is permanent damage in my opinion.  I suspect that the frequency of operation is too high for the load to work properly.  It may be necessary to start with a minimal configuration (no GEL/memory map) and manually re-configure the PLL via memory window writes, then try to load the GEL/program you are trying to load.

Regards,

Karl

Karl,

Sorry for my ignorance, but as a new user of TI microcontrollers, I'm only familiar with CCS and HALCoGen.

Could you explain:

1. What constitutes a minimal configuration?

2. How to manually reconfigure the PLL via "memory window writes"?

It appears to me the failure is on a GEL script, likely loaded on-connection to device.  What I would recommend is to remove any GEL script from your startup/on-connect options, then try to connect the device directly.  If you can open a memory window and write the PLL configuration registers directly to disable the PLL, you should then be able to regain control and reflash.  Sorry but I have not touched HALCoGen or CCS directly in a couple of years, so I am not able to give step by step instructions.

Regards,

Karl

Ok, I understand about using the memory window to write the PLL, but I wasn't aware there were script files being run.   I assume they are part of the CCS project file?  If not, where would they be located?

The error message noted is from a GEL script.  It has been a while since I've used CCS, but in the target config I believe you have the option to run an initialization script.  Many targets will come with a default script, which can be disabled (at least temporarily) by adjusting the target config files.

Regards,

Karl

Karl,

I've looked and search for "GEL", and scripts, but can't find any files in the project directory.

Do you now the name or extension of the GEL script?

William,

Can you try the following and let me know the result. (I'm actually in business trip and don't have a board to do screen capture)

1] Start CCS
2] Open Target Configurations Window.
3] Right click on your target configuration for your device.
4] Click on Launch Selected Configuration.
5] A new window (Debug) should be open.
6] Right click on the entry in this window and select Show all Core.
7] Right click on "Icepick" and select "Connect"
8] Icepick should be connected now.
9] right click on "DAP" and select "Connect"
10] DAP should be connected now.
11] Right Click on Cortex_R4 and select "Connect"
12] Cortex_R4 should be connected.

Please let me know if this sequence is working. If not, at what stage is it failing?

I don't get the selections that you list.

Can we do a webex meeting so you can see my system?

William,

I'm in business trip in Germany for 2 weeks. 
I can setup a webex for tomorrow.
The best is to email me when you are available and I will let you know my availability.
From my hotel room the connection is too slow to run a webex right now.

I've send you a friend request so we can exchange direct email and phone number.