I have a fully working firmware developed on the iMX7D-512 on WEC2013. I wanted to try it on the iMX6D-512 in case I needed for graphics power. The I/O is all modeled on the Aster board design. The firmware will run on the Aster with the iMX7D even without the module being connected to my baseboard – it just reports some missing I/O responses that come from my baseboard.
However, the iMX6D runs to a point at the start of the app and then starts to slow. It eventually transfers all compute usage from the firmware exe to the NK.bin (kernel). The kernel then saturates one core and the whole of WEC2013 slows so much as to be unresponsive in any practical sense. The shell interface runs slower and slower until an eventual apparent freeze.
I can’t seem to debug this as nothing in my firmware throws a trackable error. This happens on both the Aster carrier and my own baseboard with I/O modeled on the Aster board.
Any hints on how to debug this? Could it be a kernel error with WEC2013 on the iMX6D-512? I have installed the latest available WEC2013 version.
Do I need to specify GPIO speeds on every I/O pin on the iMX6D? What is the default speed?
It looks like the library is up to version 2.5 now.
I should note that we purchased the source code option for the GPIOLib because I have some customized byte-wide read/writes to support emulation of an 8-bit PC/104 bus. Do I need updated source code for 2.3 → 2.5 for the GPIOLib?
Could you please share a full log starting from the system boot?
“I have some customized byte-wide read/writes” Is your changes compatible with iMX6 SOC?
Can you connect a VS debugger and check which application’s system call causing core saturation?
Could you please try to disable GPU:
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Clock]
"Enable2D3D"=dword:0 ; GPU will not be powered-up at boot
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\GCHAL\]
"Dll"="_libGALCore.dll" ; prevent GPU driver loading, otherwise it will stop and prevent boot completition
I assumed that the pin # on both the iMX7D and iMX6D would be in the same location in the GPIO register map since the Aster supports both. However, that does not seem to be the case. The GPIO pins apparently are shuffled around into different registers/bit locations.
In the interest of speed, we selected the iMX7D GPIO pins for the PC/104 8-bit data bus emulation to be contiguous and in the same I/O register. It appears the pin-to-I/O register assignments get shuffled in the iMX6D. So I am likely not writing correct I/O to my baseboard.
I will work on fixing that first, and then I will see if the hangup is still present.
Good news. It was the I/O map change between the same pins for the iMX7D vs. the iMX6D. Once I edited my GPIOLib functions to account for that difference, the hangup in CE 8 is no longer present.
In case it helps someone else, here is one way of mapping an 8-bit PC/104 bus into the GPIO. With minor code modifications you can do contiguous, parallel 8-bit read/writes on the bus and convert your 8-bit PC/104 projects on X86 to the Toradex modules.
