Debugging i.MX6S SoloX SABRE-SD using IAR and Segger

[andrewwayner]

I am running into problems trying to do simple debugging on my i.MX6 SoloX SABRE-SD board. I will first provide background and then provide my list of questions.

BACKGROUND

--------------------

I am using IAR 7.40.2 and a Segger J-link probe. In the documentation that came from Freescale with my SABRE-SD it clearly stated that the only debugging tool supported was the TRACE32 from Lauterbach. I contacted IAR and Segger and found that IAR supports the bare-metal cores and Segger provided me J-Link scripts to be able to start debug sessions, staring with bringing up the A9 followed by the M4 as expected.I have created two very simple bare-metal projects, one for the A9 and one for the M4. Both projects are compiled and linked using the default Cortex-A9 linker command file provided by IAR.The M4 executable is stored in QSPI using U-BOOT (as described in Freescale documentation) and the A9 project is designed to copy this M4 executable from QSPI to the M4 TCM (0x7F8000 - 0x807FFF) and then enable the M4 core.

Currently, my only way to boot the SABRE-SD is using the U-BOOT. I interrupt the autoboot after I apply power (or reset). At this time I am able to start a debug session on the A9 from IAR. I run the A9 project and the M4 core is loaded and begins to execute. I know that the core is running as I can observe from the A9 core that a location in the M4 TCM address range being written to by the M4 core.

PROBLEMS / QUESTIONS

-----------------------------------

1) Does Freescale have (or plan to have) improved IAR debugging support for the i.MX6 SoloX (in particular device description files (.ddf) and other necessary macros for debugging)?

2) Does the U-BOOT modify the A9 core's memory map? I am able to access the M4 TCM as stated above, but I do not seem to be able to access DDR or OCRAM by using the address ranges specified in Table 2-1 of the reference manual. For example, I write to addresses 0x00900000 and 0x80800000 from the M4 core (which I can see from the debug memory window these write took effect) but a read of the same addresses on the A9 core show no change in data. I have also tried to disable any caching effects by running the command "dcache flush" from U-BOOT prior to starting my A9 debug session but this had no effect. Please advise as to what I am doing wrong and why my A9 application does not have a valid memory map.

3) Are there any or bootloaders provided by Freescale other than U-BOOT for the i.MX6 SoloX? It would be nice to have a much simpler bootloader to use as a base for initial development, especially compatible with bare-metal debugging.

4) I am unable to read correct QSPI2B memory in my IAR debug memory window of my A9 project if I had previously run the "sf probe 1:0" command at the U-BOOT prompt (data is all 0xFFFFFFFF). If I do not run this command then I am able to read the QSPI2B just fine (though it needs to be read 64-bit wide and the endianess is wrong). This had worked before, but somehow during my debugging I have botched something. This seems to only affect my QSPI2B memory as I am able to read the QSPI2A memory regardless if I run the "sf probe 0:0" command. Can you suggest what I may have corrupted in the A9 core or the QSPI2B memory that would cause the IAR debug memory window (which uses the JTAG interface to read memory) to behave incorrectly in this fashion?

[igorpadykov]

Hi Andrew

IAR tools are provided by www.iar.com and usually

debugging support is provided by tools vendor.

I am not aware of other bootloaders, except uboot for the i.MX6 SoloX.

For qspi and TCM I would suggest to look at below examples

MX6 SoloX bare metal startup

Best regards

igor

[andrewwayner]

I just realized something which may help the answer to my question #4 above. When I read from QSPI2A (which is the QSPI that is still functioning normally) the bytes are ordered as expected per the .bin file I have written there. The QSPI2B (which is the one acting funny) has the endianess wrong. Somehow I switched the endianess and it is permanent (survives reset and power off and not affected by changing of SD cards). Is there some CPU register or QSPI2B memory location that I may have corrupted that can cause this behavior?