nRF51822-QFAC custom board with wrong baudrate

RE: nRF51822-QFAC custom board with wrong baudrate

allankliu — Wed, 06 Sep 2017 04:06:40 GMT

Hi, Jørn

Thanks for your support and follow up. With my new RF module, I did more labs. Now TXD works well after disable HWFC in CONFIG in the source file. Well, set HWFC to false is not enough at all, since this Macro is not used in source file anyway. I put my labs here.

So, baremetal UART demo works, I am going to test BLE/UART demo this afternoon. I will turn to your help if I ran into other issues. :)

UPDATE

The BLE UART demo works.

RE: nRF51822-QFAC custom board with wrong baudrate

Jørn — Tue, 05 Sep 2017 13:36:23 GMT

I think it might be necessary to see the schematics and layout of your custom board to see if anything there might be the issue. If your project is not confidential you can upload it to your original question here. If it is confidential you can create a mypage ticket at nordicsemi.com and refer to this case.

RE: nRF51822-QFAC custom board with wrong baudrate

allankliu — Tue, 05 Sep 2017 12:24:37 GMT

I changed to another prototype board, it seems the situation is the same. BLE works, UART doesn't, baremetal UART doesn't work too.

I am confused, it is a hardware issue or firmware issue ? Is it anything to do with differences between nRF51822 and nRF51422? Or should I take care the GPIO pull-up/sink current?

RE: nRF51822-QFAC custom board with wrong baudrate

allankliu — Sat, 02 Sep 2017 01:45:56 GMT

Thanks Jørn,

This is not the final custom board, I designed it for evaluation and development, if BLE works, than I will wire RX/TX to my LoRa/Sub-1GHz radio board. I am a software engineer, so I want a platform to develop my firmware, rather than PCB debug and RF tuning.

Here are my answers for your questions.

Keypad stands for Key Matrix in NORDIC_Toolbox/UART_APP.
In the circuit, I used a off-the-thelf nRF modules instead of nRF51822 silicon, there are 16MHz and 32.768KHz crystal oon board.
I actually used the same project defined for PCA10028, only custom_board.h and Preprocessor are altered.

Since BLE communication is quite successful, I think crystal is good enough for BLE and UART. since baudrate is much lower than 16MHz, even crystal's PPM is good enough, if we slow down the baudrate, it should be stable.

Regarding the baremetal example lab, I have done that already before going to this post, as I mentioned in the very beginning. But I will double confirm with latest SDK.

I ordered two more kits (nRf51822/nRF52832) from another local supplier as cross-checking, because I doubt if there is anything wrong related to the module itself. It is strange, that I run into so many issues although I have bought may kits, several are phased out due to silicon version. Serveral are not official boards.

If these kits are not working well, It will be helpful If your local branch in China can arrange a kit for my evalution, I will return it back to your local office.

RE: nRF51822-QFAC custom board with wrong baudrate

Jørn — Fri, 01 Sep 2017 13:57:31 GMT

Hello allankliu

I will need some additional information from you.

You say you press the "keypad", I assume you mean keypad on your phone? The circuit in the picture you posted would not be capable of BLE so I assume it is not of your current custom board. Are you using the same project on your custom board, as you did on the pca10028? Other than the custom_board.h file, have you altered the project in any way?

Regarding the pictures you posted:

I see you do not have a crystal for the nRF51822, which means you are using the internal RC oscillator. The internal oscillator has, according to the nRF51822 specification, a frequency tolerance of +/- 1-5 %. It is this clock that generates the UART clock.

From what I have found the CH340G uses a 12MHz crystal. I have not found anything about clock accuracy. However the datasheet states

Transmitter baud rate error is less than 0.3%, receiver baud rate error tolerance is at most 2%

You are not using any hardware flow control, which means you are very dependent on accurate clocks at both ends (you are anyway but even more so without HWFC). The baud rate error tolerance of the CH340G is stricter than the accuracy of the nRF51822 16MHz RC oscillator, this could possibly cause problems.

If you are sending your data via BLE on your custom board then you must have a 16/32MHz crystal, as the radio wouldn't work without it. This should eliminate this as the crystal oscillator has a higher accuracy.

I would recommend you try to get serial communication between the nRF and the CH340G working without BLE first. You can find the hardware example at SDK_Folder/examples/peripheral/uart, or if you want a bare-metal example you can look here.

Best regards

Jørn Frøysa