nRF51822-QFAC custom board with wrong baudrate

[allankliu]

Story and Official Code Test Passed

I am trying to integrate BLE into Smart-Lock and LoRa Terminal. So I build a custom board with off-the-thelf modules to evalute and integration. In both projects, nRF51822 may connect to a host micro via UART.

As I metioned in anther thread here. It is wired that nRF51822 uart TXD seems running at wrong baudrate. Nordic team suggested me to try latest SDK, I did this morning. Here is my log.

1. Download the SDK-v12.3.0, unzip it ;
2. Update softdevice to s130_2.0.1.hex inside nRF51822-QFAC with OpenOCD/ST-LINKv2;
3. Open MDK5 project located in **C:\Nordic\nRF5_SDK_12.3.0_d7731ad\examples\ble_peripheral\ble_app_uart\pca10028\s130\arm5_no_packs** ;
4. Build and program firmware into nRF51822 application flash with ST-LINKv2, bring up debugger;
5. Running Nordic_toolbox in Android phone ;
6. Scan, Connect to Nordic_UART device ;
7. Define custom keypad with strings ;
8. Set breakpoint inside MDK5 debugger
9. Press keypad, breakpoint hit, and strings received are verfied correctly.

Everything is running OK for official project ! That proves ST-LINKv2/OpenOCD/MDK5 can work and debug as a complete toolchain.

Custom Code UART Baudrate

So I moved on.

1. Clone PCA10028.h and rename it to custom_board.h in the path of C:\Nordic\nRF5_SDK_12.3.0_d7731ad\components\boards ;
2. Change PIN definitions in custom_board.h ;
3. Change Preprocessor Symbols, rename BOARD_PCA10028 to BOARD_CUSTOM ;
4. Rebuild project, download, bring up debugger ;
5. Open TeraTerm Serial session, identified UART as COM8 in PC, in baudrate 115.2kbps ;
6. Scan, connect to device, successful ;
7. Press keypad, strings print to TeraTerm are rabbish strings,

Actually, I have solved some other issues such as device can not detected, and wrong TXD/RXD. Now the final UART doesn't work well anyway. We can remove suspects from following items:

1. SDK not up to date;
2. Toolchain, proved in official code flow;
3. TXD/RXD, set HWFC to false, and PIN pairs are correct;
4. Xtal，since 16MHz is used for whole system, it should be OK.

Next Step ?

Since the code/flow/toolchain/connections are correct, I have to check if there is any hardware related issues.

My UART definitions are:

#define RX_PIN_NUMBER  4
#define TX_PIN_NUMBER  2
#define CTS_PIN_NUMBER 22
#define RTS_PIN_NUMBER 3

#define HWFC           false

**Is there any cautions for custom GPIO for UART ? or any support circuit requirements ? ** If necessary, I can cut the wire and connect to anther GPIO.

Actually I have done and passed a local loop test for USB/UART, by short circuit TXD/RXD to double check if it is OK in a console terminal. In order to test that, firmware is removed first. And in TeraTerm, every char I entered can be displayed without local echo. So USB/UART works fine.

And I will use another micro to test the nRF51822 UART as close as possible to check if there is some noise nearby. Maybe I will use oscilloscope and logic analyzer for touble shooting.

However things doesn't get better in my project.

Attachements

In order to allow people to have an overview, I shared my schematics/PCB here.

Fig1: Schematics. A simple circuit to connect nRF51822 to CH340G, powered by 3V3 LDO.

Fig2: PCB, 2 layer, with copper pour

custom_board.h

File1: custom_board.h

---

UPDATE 01

Today I have done some more labs as cross-checking.

1. Replace RXD/TXD to another GPIO
2. Try barematel peripheral demos without BLE stack, aka. softdevice.

The first lab result is as same as current GPIO definitions. So it seems nothing to do with RF module layout issue, since it is not a problem happens on specific GPIO.

The second lab doesn't print any chars at all.

I have ordered another RF modules for nRF51822 and nRF52832. Unfortunately, P0.10/P0.11 of nRF51822 is short circuit somethere in the module, while nRF52832 is good. So at lease I have to define CTS to another pin to test the official code. I will update this thread ASAP.

UPDATE 02

Well, since my new RF module has fanned out most of the GPIOs, so I can download the original project and modify the code for specific applications. I started from baremetal GPIO blinky, then baremetal UART, finally BLE UART. During these steps, I identified one issue for wrong silkscreen, so I corrected my pinout, then I identified the HWFC definitions in firmware, so I updated the source code anyway. And it think MDK5 register view window is quite helpful during my debug. Thanks to register window, I can confirmed that GPIO and UART are working well or not.

However, after confirmation in my new breakout board, I will go on to test it on my old custom board to check if there is anything wrong with schematics or PCB layout.

[Jørn]

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

[allankliu]

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.

1. Keypad stands for Key Matrix in NORDIC_Toolbox/UART_APP.
2. In the circuit, I used a off-the-thelf nRF modules instead of nRF51822 silicon, there are 16MHz and 32.768KHz crystal oon board.
3. 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.

[allankliu]

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?

[Jørn]

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.

[allankliu]

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.