Configuring PSOC 4 DTM/HCI example for high speed UART.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
PeTy_2173191
Level 2
Level 2

Hello,

   

The DTM/HCI example works fine for speeds up to 115200 baud.

   

However for higher speeds the systems fails due to improper clock setup.

   

How to setup the clock for e.g. 460800 baud?

   

At 24Mhz and divider 3 i get: 8Mhz which is a bit from the optimal 7.373 which will give bit errors once in a while (and it does).

   

Changing the IMO to 30Mhz gives a nicer 7,5Mhz.... but then it stops working all together. Not sure why. Should work better, but the entire system seems to stop working.

   

It is a bit unfortunate that the DTM does not work out-of-the-box with anything above 115200. At 115200 it is a bit hard to use the "data packet length extension" for anything as that would require much higher bandwidth at full speed.

   

How do i resolve this, so i can run faster on the UART in the DTM/HCI example? Is this a bug and/or missing feature?

   

/pedro

0 Likes
1 Solution
PeTy_2173191
Level 2
Level 2

Aha! I figured it out.

   

It is not broken, but a bit lacking on the documentation.

   

The 9600 -> 115200 is actually working if you configure the RTS/CTS correctly!

   

To get higher speeds to work you have to cheat! When setting the UART to e.g. 460800 you really have set set it to 500000.

   

This is probably because their favorite frequency is 24Mhz.

   

This is done in the example automatically if you try to set it to 460800 as the nearest sampling frequency is stated as 8Mh in the DTM example.

   

With the OVS needed, This gives exactly 500000, as 8000000/16 = 5000000

   

The UART/USB converter in the Pioneer kit knows this and compensates. So one side will be running 500000, and the other will be running the correct 460800 (towards the PC).

   

Only catch left is that that if you cannot keep up speed-wise on the PC, you are going to loose packets no matter what.

   

Thanks,

   

/pedro

View solution in original post

0 Likes
6 Replies
PeTy_2173191
Level 2
Level 2

By the way i am trying this on the CY8CKIT-042-BLE-A pioneer kit.

   

The mounted module is BL538.

0 Likes
PeTy_2173191
Level 2
Level 2

I tested all speeds from 9600 -> 115200 using continuously hammering the controller with 1 byte packets over and over from another PC over BLE.

   

9600: OK

   

14400: OK

   

38400: BAD. After a while a bad byte pops up over the UART.

   

I have not scoped this, so i do not know if it is the module or the pioneer board that is failing.

   

However, probably someone from Cypress should look at this, as the current stability is not really usable.

0 Likes
PeTy_2173191
Level 2
Level 2

I am by the way using the latest PSOC creator and the latest DTM example.

0 Likes
PeTy_2173191
Level 2
Level 2

I tried rebuilding the project from scratch with the other module (CYBL11573-56LQXI).

   

Same result. Everything above 14400 produces garbage after a while.

0 Likes
PeTy_2173191
Level 2
Level 2

I tried using an external UART <-> USB. Same problem.

   

I scoped the lines. Definitely coming from the module. Not noise.

   

So i guess this is a bug in the DTM firmware which is completely closed source.

   

Any fix for this from Cypress?

0 Likes
PeTy_2173191
Level 2
Level 2

Aha! I figured it out.

   

It is not broken, but a bit lacking on the documentation.

   

The 9600 -> 115200 is actually working if you configure the RTS/CTS correctly!

   

To get higher speeds to work you have to cheat! When setting the UART to e.g. 460800 you really have set set it to 500000.

   

This is probably because their favorite frequency is 24Mhz.

   

This is done in the example automatically if you try to set it to 460800 as the nearest sampling frequency is stated as 8Mh in the DTM example.

   

With the OVS needed, This gives exactly 500000, as 8000000/16 = 5000000

   

The UART/USB converter in the Pioneer kit knows this and compensates. So one side will be running 500000, and the other will be running the correct 460800 (towards the PC).

   

Only catch left is that that if you cannot keep up speed-wise on the PC, you are going to loose packets no matter what.

   

Thanks,

   

/pedro

0 Likes