We're using JLink PRO and JLinkGDBServer on Linux to connect to our IMX6 (MCIMX6S7 CPU), however when uploading code to RAM it locks up trying to run it with a SIGTRAP on the load address.
It needs a power cycle before JLink can connect to it again.
The error message on failure to connect reads:
The JLinkGDBServer is started with the following parameters:
We connect with GDB use a script to setup the DRAM timings and IOMUX pad settings, in addition we run 'monitor reset' and disable the watchdog with 'monitor WriteU16 0x020bc000 = 0x30' and enable all clocks.
After the RAM is set up we issue a 'load' command in GDB to upload the code to ram. Then use 'continue' to start the application. This is where everything crashes when using the MCIMX6S7 device parameter.
I've read on this forum and elsewhere that we really should use the correct device with IMX CPUs, however when using 'cortex-a9' as the device type. The first load works without issues, but in order to reset the device (with 'monitor reset'), the DRAM settings and code upload must be performed twice in order to avoid the CPU jumping back into ROM code.
So I'm thinking the restart issue might be fixed if we're able to use the correct deivce target, but we cannot get it to work.
Any suggestions?
It needs a power cycle before JLink can connect to it again.
The error message on failure to connect reads:
The JLinkGDBServer is started with the following parameters:
We connect with GDB use a script to setup the DRAM timings and IOMUX pad settings, in addition we run 'monitor reset' and disable the watchdog with 'monitor WriteU16 0x020bc000 = 0x30' and enable all clocks.
After the RAM is set up we issue a 'load' command in GDB to upload the code to ram. Then use 'continue' to start the application. This is where everything crashes when using the MCIMX6S7 device parameter.
I've read on this forum and elsewhere that we really should use the correct device with IMX CPUs, however when using 'cortex-a9' as the device type. The first load works without issues, but in order to reset the device (with 'monitor reset'), the DRAM settings and code upload must be performed twice in order to avoid the CPU jumping back into ROM code.
So I'm thinking the restart issue might be fixed if we're able to use the correct deivce target, but we cannot get it to work.
Any suggestions?
The post was edited 1 time, last by KnutT ().