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?
Could you please provide more details about your case?
- WEC2013 BSP version you are running on Colibri iMX7 and iMX6
- Library version you are using to access GPIO and other peripherals
- HW revisions of your modules
- What exactly does “It eventually transfers all compute usage from the firmware exe to the NK.bin (kernel).” mean in your case?
- Which thread(s) does “saturates one core and the whole of WEC2013” ?
Could you enable Debug Messages over Serial and collect logs?
I thought I was running identical CE 8 versions, but apparently not:
Toradex Windows CE 8.0 1.3b2 for iMX7 Built Aug 1 2019
Toradex Windows CE 8.0 1.6 for iMX6 Built on Dec 23 2019
SDK and libraries:
Toradex CE8 SDK v2.3
iMX7D - 1.1D
iMX6D - v1.1a
See the attached image. It shows how my Model430.exe has dropped to 0% CPU usage and the NK.exe has saturated one core (50%).
I enabled debug port on the Aster and ran my firmware on the iMX6D. It reports:
GC2D FATAL ERROR:2D hardware hung (timeout:3000)!
GC2D FATAL ERROR:2D hardware hung (timeout:6000)!
GC2D FATAL ERROR:2D hardware hung (timeout:9000)!
GC2D FATAL ERROR:2D hardware hung (timeout:12000)!
GC2D FATAL ERROR:2D hardware hung (timeout:15000)!
GC2D FATAL ERROR:2D hardware hung (timeout:18000)!
and so on…
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:
"Enable2D3D"=dword:0 ; GPU will not be powered-up at boot
"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.
Thank you for the update. Glad you problem is solved.