I’m porting an application from the Colibri T20 to the Colibri iMX6D and have noticed something odd. Our T20-based application has successfully used the ConfigBlockEditor in batch mode to disable the splashscreen for quite a few years, because we use some of the pins as GPIOs to control hardware.
I use Sys_GetConfigInt(hSys, L"PID8", &pid8.Val) to read the module type so that I configure the GPIO pins a little differently due to the different pin multiplexing on the T20 and the iMX6.
But on the iMX6 I have found that after I run ConfigBlockEditor that subsequent calls to Sys_GetConfigInt(hSys, L"PID8", &pid8.Val) return bad data in pid8. It keeps returning bad data until I reset the module, and then if I run ConfigBlockEditor again the problem returns.
I am using v1.13 of the ConfigBlockEditor win WinCE 7 image 1.8.
The batch file that I send to ConfigBlockEditor is:
setconfig ss.enable = 0
saveconfig ss
Could you please explain - Why do you need to disable Splash Screen by your app?
You can disable it once (either by eBoot menu or ConfigBlockEditor) install your app and then backup everything using the Update Tool. Then you can use that backup for production programming.
We disable the splash screen because we use some of the display panel pins as GPIOs which drive motors. The motors make an unpleasant chattering noise during booting if the splashscreen is being displayed, before the firmware takes control of the pins. Not the best hardware design perhaps, but it is what we have. To avoid that we use the ConfigBlockEditor to configure some pins as GPIO and disable the splashscreen.
These settings are already captured in the image we use for production programming. The software engineer who implemented this did it in such a way that the ConfigBlockEditor is run every time our software boots, which seemed to be OK on the T20. I am going to change this so that it is only written once and the result is then stored in the registry so we know that this has been done already on this module. It will be better not to keep writing to the config block over and over anyway.
