90-days-license: "AM3359_ICE_Initialization() cannot be evaluated"

(edit: Martin was faster than me in replying. Although the explanations below are still valid, they are obviously not applicable to the issue at hand)

Martin,

As you spotted correctly, this error is coming from a GEL initialization file, which has no relationship with the CCS license. Also, unless the adapter is suffering bad or intermittent contacts, a GEL error is only loosely related to the physical adapter itself since the error would probably manifest itself at an earlier stage of the connection process.

On the other hand, the GEL file is tightly coupled with the hardware it is running, therefore in this case you have to be sure of the following:

- To isolate the issue either on the GEL file or on the target itself, I would remove the GEL file, connect to the target core, open the Memory Browser and try to read the contents of the address 0x44E10040.

- If you can't, then the target board is preventing access to the register. This is usually caused by either software already running on the target (Linux, etc.) or somehow the processor is protecting this area (perhaps MMU is on?)

- If you can, then the GEL file is performing an operation that is blocking this specific access. This is probably caused by the differences in the target boards.

Hope this helps,

Rafael 

Martin H. said:

Target failed to read 0x44E10040
   at (*((unsigned int *) (0x44E10000+0x40))>>22) [TMDXICE3359_v2_1A.gel:383]
   at GetInputClockFrequency() [TMDXICE3359_v2_1A.gel:454]
   at ARM_OPP100_Config() [TMDXICE3359_v2_1A.gel:372]
   at AM3359_ICE_Initialization()

This is due to SYSBIOS enabling the MMU which then causes the GEL script to fail.

If you see the error again, try configuring CCS to generate a system reset before loading the program - see http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/317266.aspx

Hi,

thanks for your interesting information.
I am afraid I have been to euphoric when I thought the problem was solved.

That read error was gone and instead a memory verification error at address 0x80000000 was shown.
Now the read error at 0x44e1 0040 (that origins from the gel file) is back.

I have made a new target configuration file, selected AM3359, checked "Reset target on program load or start" and did not specify an
initialization script.
Then I connected to the target. The memory browser then only displayed question marks at address 0x44E1 0040.
So I suppose you are right, Rafael. The boot procedure copies LINUX from NAND flash to RAM and that prevents access to memory. Doing a reset on program load does not help because the gel script cannot not be run to initialize the board.
How should one proceed?
Delete the NAND flash and see if that helps?
I have set a hardware breakpoint at 0x8000000, hoping that the 1st bootloader would jump there looking for the 2nd bootloader. But
that did not help.

Regards,
Martin H.

Martin H. said:

I have made a new target configuration file, selected AM3359, checked "Reset target on program load or start" and did not specify an
initialization script.
Then I connected to the target. The memory browser then only displayed question marks at address 0x44E1 0040.
So I suppose you are right, Rafael. The boot procedure copies LINUX from NAND flash to RAM and that prevents access to memory. Doing a reset on program load does not help because the gel script cannot not be run to initialize the board.2
How should one proceed?

Hopefully this will allow a target connect even if the device has booted from flash.

[I haven't got a AM335x device booting Linux from flash to test at the moment, but this suggestion was the verified answer to the similar problem in https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/413431]

Hello,

I followed your advice and this time I checked "Reset the target on a connect".
It brought me a bit further with the gel file, but this time I got an error writing to the EMIF0 Configuration register:

CortxA8: Output: Input Clock Read from SYSBOOT[15:14]: 25MHz
CortxA8: Output: **** AM3358_SK Initialization is in progress ..........
CortxA8: Output: **** AM335x ALL PLL Config for OPP == OPP100 is in progress .........
CortxA8: Output: Input Clock Read from SYSBOOT[15:14]: 25MHz
CortxA8: Output: **** Going to Bypass...
CortxA8: Output: **** Bypassed, changing values...
CortxA8: Output: **** Locking ARM PLL
CortxA8: Output: **** Core Bypassed
CortxA8: Output: **** Now locking Core...
CortxA8: Output: **** Core locked
CortxA8: Output: **** DDR DPLL Bypassed
CortxA8: Output: **** DDR DPLL Locked
CortxA8: Output: **** PER DPLL Bypassed
CortxA8: Output: **** PER DPLL Locked
CortxA8: Output: **** DISP PLL Config is in progress ..........
CortxA8: Output: **** DISP PLL Config is DONE ..........
CortxA8: Output: **** AM335x ALL ADPLL Config for OPP == OPP100 is Done .........
CortxA8: Output: **** AM335x DDR3 EMIF and PHY configuration is in progress...
CortxA8: Output: EMIF PRCM is in progress .......
CortxA8: Output: EMIF PRCM Done
CortxA8: Output: DDR PHY Configuration in progress
CortxA8: Output: Waiting for VTP Ready .......
CortxA8: Output: VTP is Ready!
CortxA8: Output: DDR PHY CMD0 Register configuration is in progress .......
CortxA8: Output: DDR PHY CMD1 Register configuration is in progress .......
CortxA8: Output: DDR PHY CMD2 Register configuration is in progress .......
CortxA8: Output: DDR PHY DATA0 Register configuration is in progress .......
CortxA8: Output: DDR PHY DATA1 Register configuration is in progress .......
CortxA8: Output: Setting IO control registers.......
CortxA8: Output: EMIF Timing register configuration is in progress .......
CortxA8: Trouble Writing Memory Block at 0x4c0000e4 on Page 0 of Length 0x4: (Error -1065 @ 0x3D5A) Unable
to access device memory. Verify that the memory address is in valid memory. If error persists, confirm
configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation
package 5.1.641.0)
AM3358_SK_Initialization() cannot be evaluated.
Target failed to write 0x4C0000E4
at *((unsigned int *) (0x4C000000+0x0E4))=(unsigned int) 0x07 [AM3358_StarterKit_MT41J256M16-
15_400MHz_DDR3 - Copy.gel:284]
at DDR3_EMIF_Config() [AM3358_StarterKit_MT41J256M16-15_400MHz_DDR3 - Copy.gel:373]
at AM3358_SK_Initialization()

These are the lines in the gel file:

....
//IO to work for DDR3
WR_MEM_32(DDR_IO_CTRL, RD_MEM_32(DDR_IO_CTRL) & ~0x10000000 );

//CKE controlled by EMIF/DDR_PHY
WR_MEM_32(DDR_CKE_CTRL, RD_MEM_32(DDR_CKE_CTRL) | 0x00000001);

GEL_TextOut("EMIF Timing register configuration is in progress ....... \n","Output",1,1,1);

WR_MEM_32(EMIF_DDR_PHY_CTRL_1_REG, ALLOPP_DDR3_READ_LATENCY);               <-- this line is causing the error

...

My first idea was that the memory is not defined, but the gel file contains a definition:

OnTargetConnect()
{
GEL_MapOff();
GEL_MapReset();
...
GEL_MapAddStr(0x4C000000, 0, 0x01000000, "R|W", 0); // EMIF
...
GEL_MapOn();
AM335xStartState();
AM3358_SK_Initialization();
Disable_Watchdog();
}

This gel file has been written for an AM3358 while my board has an AM3359. But I don't thing this makes any
difference as the AM3359 too has that memory range of 0x4C00_0000 to 0x4CFF_FFFF for EMIF0 as well.

So the big question is what prevents writing to the EMIF0 Configuration register?
Is there anything I can add to the gel file that makes this memory block writable?

Regards,
Martin H.

Hi,
I did not find the reason for that write error (perhaps somebody knows it and can tell us?).
The workaround is to change the boot order and exclude the NAND flash from booting.
That makes the GEL file run.

The next error comes up when loading the program file:

CortxA8: File Loader: Verification failed: Values at address 0x0000000080000000 do not match Please verify target memory and memory map.

I found a good description for that problem but did not yet have the time to investigate.

As soon as a solution has been found I will post it here. Comments are welcome!

Regards,
Martin H.

Martin H. said:

I followed your advice and this time I checked "Reset the target on a connect".
It brought me a bit further with the gel file, but this time I got an error writing to the EMIF0 Configuration register:

If "Reset the target on a connect" wasn't selected on the IcePick_D_0 then the CCS GEL script failed with:

CortxA8: Output: EMIF Timing register configuration is in progress ....... 
CortxA8: Trouble Writing Memory Block at 0x4c0000e4 on Page 0 of Length 0x4: (Error -1065 @ 0x3D5A) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.1.641.0) 
CortxA8: GEL: Error while executing OnTargetConnect(): Target failed to write 0x4C0000E4
	at *((unsigned int *) (0x4C000000+0x0E4))=(unsigned int) 0x7 [AM3352_SOM.gel:284]
	at DDR3_EMIF_Config() [AM3352_SOM.gel:365]
	at AM3352_SOM_Initialization() [AM3352_SOM.gel:352]
	at OnTargetConnect()

If "Reset the target on a connect" was selected on the IcePick_D_0 then CCS could run the GEL script and download a program without error.

Therefore, I don't know why you are seeing errors after checking "Reset the target on a connect". Try enabling CCS Debug Server Logging and posting the debug server log after a failure, to see if that identifies the reason for the failure.

Hi Chester,

sorry for the late reply.

As mentioned in my last post, the verification error still exists.
So I did as you recommended and recorded the file DebugServerLog.log (please see attachment). The Debug Server Log has been enabled immediatly after the Cortex A8 target connected and before "Load program .. " has been clicked.
Does that file provide you with any helpful information?
I also attached the .gel file, just in case it contains something suspicious. However, it does not display any errors in the console view.

Thank you!
Regards,
Martin H.

Attachment:
DebugServerLog.log
AM335_StarterKit_MT41J256M16-15_400MHz_DDR2-Copy.gel

AM3358_StarterKit_MT41J256M16-15_400MHz_DDR3 - Copy.gel

DebugServerLog.log

Martin H. said:

The workaround is to change the boot order and exclude the NAND flash from booting.

If I leave that SD card plugged in then CCS is not able to download a program when attempt to start a debugging session, due to reporting errors about not being able to write to memory. When attempt to start a debugging session then the UART0 output reports that the MLO program on the SD card has enabled the MMU, which I think means the following sequence:

a) CCS issues a System Reset via the IcePick (as requested by the debug properties)

b) The System Reset causes the ROM to start the boot sequence.

c) The ROM loads the MLO image from the SD card, which gets to enabling the MMU.

d) By the time CCS attempts to download the program the MMU has been enabled which prevents CCS from being able to access the device memory.

I tried to use the "Wait In Reset" option to prevent the ROM from starting a boot, but so far have failed to get the "Wait In Reset" to prevent the problem.

Hi Chester,

in my case there is no SD-card plugged.
Also with the boot order MMC1, MMC0, UART0, USB0 the system should not boot.

Perhaps the SDRAM at 0x80000000 is not initialized correctly?
After connection of the Cortex A8 probe I keyed-in some values at adddress 0x80000000 using the Memory Browser.
This is the result:

written                 read
---------------------------
0x12345678     0x120056DD
0x34567812     0x340078DD
0x56781234     0x560012DD
So the first and the 3rd byte seem to be ok, but the others are not.

Writing to
   0x80000004, 0x80000008, 0x8000000C and
   0x80000014, 0x80000018, 0x8000001C and
   0x80000004, 0x80000008, 0x8000000C
is ok., i.e. the Memory Browser displays exactly the value that has been keyed-in

But writing to
    0x80000000, 0x80000010, 0x80000020
provides wrong values, with the 1st and 3rd byte being correct.

Can you think of a reason for that behaviour?
Should I buy a different JTAG emulator?
Running Ubuntu does not result in any error messages, so I would asume that the RAM is not faulty.

The .gel file is for a AM3358, but should that make any difference regarding SDRAM initialization?

Inspired by the article "Troubleshooting CCS - Data Verification Errors" I reduced "The JTag TCLK Frequency" to "Fixed with user specified slower value" of 100kHz. But that made no difference.

Regards,
Martin H.

Hi Chester,

it seems the problem has been solved.
SDRAM accepts what is written by the Memory Browser and the file can be loaded now.
The reason was the RAM initialization. The manufacturer of that LINUX board says in its manual "The effective bus
is 16-bits wide."
But obviously the SDRAM initialization has to be done for a bus width of 8 bits. I used another gel file and that
did the job.
Thank you very much for your support and patience!

Kind regards,
Martin H.