Colibri T20 Version OS image 1.2 and in 1.4 the display is not updated properly and Sound files are not reproduced properly

I’m not sure why the driver for serial2 doesn’t load with your setup as it seems you do everything correctly. However, it seems, that disabling UART B helps. In order to solve the issue, you could use the workaround as proposed by Samuel initially. Just create a small tool which runs at the beginning (or add some code to your application before opening the serial ports) which adds a pull-up resistor to CTS. Note, when adding a pull-up to CTS of UART B, this will automatically also add a pull-up on all other UART B signals (RXD, TXD, RTS). This cannot be avoided on the T20. You can use the GPIO Library in order to set pull-resistors for signals.

Another approach would be to add a real external pull-up resistor, or try to set CTS as GPIO output 1 also using the GPIO Lib. Setting GPIOs to output can be done w/o affecting the other UART B GPIOs.

I hope one of these workarounds will help.

Hi Roman,
I have made CTS pin as GPIO output and made that status to 1, Even then the slow issue remains the same(CPU of nk.exe 60-70%).But as per the previous condition, when we disable serial 2, NK.exe cpu time is normal 10-12%.

@Gopal: As far as I can see from the postings in this issue, you never tested on any other carrier board than yours. Is this correct? Do you have to a chance to give it a quick try on one of our carrier boards?

Could you send us the relevant parts of the schematics of your carrier board, so we can quickly understand which lines are actually used and which not? You can mark a posting as private or send it by mail to if you don’t want to share the schematics with every one.

@ Samuel,
You are right, we have not made testing with your carrier board, since it can not resemble the same load what we apply on Colibri T20. Ultimately, the Colibri T20 should work in our carrier board rather than your carrier board. Moreover, it is specific to some boards, so the biasing on the hardware has some issue which is making this kind of inconsistency.

Our engineer Maha has sent you the schematic in the email ID.

Thanks. We have checked the schematics. The SODIMM Pins 34 and 32 (CTS / RTS) go to to a connector and are probably floating.

As you already tried to modify the Pull States and did not had any success, I would recommend that you once try to externally set these pins to a defined state and check if this changes the situation.

We recently released the image 2.0 beta 4 which easily allows you to set pin configurations in the Bootloader Menue. Could you once try to reproduce first the issue with the image 2.0 beta 4, and if the issue is still there add the following setting in gpio.bootconf in the bootloader:

[gpio_9] pull=down [gpio_87] pull=down

You have to add that configuration to the existing configuration, do not replace the existing gpio configuration. After that you should see in the GPIO Config Tool, that these pins are pulled down. Let me know if that helps.

Dear Samuel,
Thanks for your input.

We have updated the image to 2.0 beta 4 and now it is totally hang. The software what we have which is developed in V1.2 (SDK).

Also we tried the image 2.0 beta 4 with the software developed in V1.4 (SDK). After that also our application not working.

To develop our software with the 2.0 SDK will take more time, also we cannot execute this with the Beta version. Please don’t use us for validating your software versions.

For your kind reminder that the SODIMM Pins 34 and 32 (CTS / RTS) fixed with the state as PULL-UP using 4.7K.

And the total hang happens in your carrier board also!!.

@Mahalakshmi: That sounds good as we could reproduce that on our side as well. Is there a way you could provide us some sample code that shows the application hanging, so we could it try here. Either upload the sample code here or send it us over

Hi Samuel,
We have shared our application through
Please find.

Hai samuel,

For your kind reminder, the issue is still open!

@Mahalakshmi: Just to make sure: After you have been in direct contact with our support team, is there any pending issue on your side?

Thanks for your reply!!
Support team asked us to share our application code, but as per our QMS process we should not share the internal code to others.

Still the issue is open and totally we have fifteen T20 defective boards.

Other than code if you have any input please let us know…