Nuvoton N76E003 + GPRS serial port garbled code troubleshooting notes

aim of design

The microcontroller uses N76E003, the GPRS module uses AIR208, N76E003 uses USART0 to communicate with AIR208, and uses USART1 to communicate with another device. Due to the uniqueness of each device in service, each device number should be unique. The IMEI number of the GPRS module is unique, so the design idea is to read the IMEI number and use it as the unique number of the device.

Garbled characters appear when reading IMEI number

N76E003 sends control commands to read the IMEI number of AIR208, and then tries to locate the problem.

1. Using the serial port assistant to observe, N76E003 did send the control command, and AIR208 did return the return data containing the MEI number. The problem is that the read data is lost regardless of whether the microcontroller is running in single step or full speed.

2. Use the serial port assistant to send control commands to the GPRS module and successfully receive the returned data without loss.

3. Use the serial port assistant to send 24 bytes of data to the microcontroller, and the microcontroller successfully receives the data without loss.

It can be concluded that the microcontroller serial port can send and receive. The GPRS module serial port can send and receive.

Try a workaround

Suspicion 1: MCU parameter configuration error

The initialization function of the N76E003 microcontroller is as follows. After binding TIM3, the problem is not solved after trying to bind TIM1.

At the same time, I suspected that other MCU peripherals were enabled and caused conflicts, so I disabled/commented out all other peripherals except UART0, but the problem was not solved.

void timer0_init(void)

{

  TMOD = 0XFF;

  TIMER0_MODE1_ENABLE;

  clr_T0M;

  TH0 = (uint8_t)((65535 - 13334) >> 8); //10mS time initial value

  TL0 = (uint8_t)((65535 - 13334) & 0xff);

  set_ET0; //enable Timer0 interrupt

  set_TR0; //Timer0 run

}

Suspicion 2: GPRS and N76E003 interface level compatibility issue

1. The VBAT level is 4.0V>0.7VCC=3.5V, and the microcontroller can successfully identify the high level

2. Jump the voltage at VBAT to VCC=5V, but the problem is not solved

3. Connect the GPRS module's sending pin directly to the MCU's receiving pin. The problem is not solved, so restore the original connection.

4. The transistor was suspected to be damaged. Q1 Q2 was replaced, but the problem was not solved.

Suspicion 3: Electromagnetic compatibility and radio frequency interference issues

1. Restore the original program and use an oscilloscope to observe the MCU TX0 RX0 pins. It was found that there was a lot of noise on the MCU's transmit pin TX0. Since the GPRS module is a DTU transparent transmission module, the server received a lot of garbled codes.

2. Shield the instructions sent by the microcontroller to inquire about the IMEI number of the GPRS module and eliminate garbled characters.

3. The server sends a heartbeat command to the MCU through the GPRS module, and the MCU can return data normally. The communication process is normal. Although some noise appears in TX0 RX0 through the oscilloscope, it does not affect the overall communication effect.

Temporary disposal method

Send commands through the serial port to set the device number

All the above attempts failed and did not solve the garbled code problem; the only result was that the microcontroller could not send a command to read the IMEI number of the GPRS module, otherwise an error would occur. So the temporary solution is to use the computer serial port assistant to send control commands to the device one by one to set the unique serial number of the device.

Final solution

Modify the serial port sending function

If you keep thinking about it, it will come true. The problem was not solved, and the author kept thinking about where the problem was. Finally, a flash of inspiration came to me. The microcontroller sent a garbled command to read the IMEI number. Was the problem in the sending function? The problem was here.

Original serial port sending function

void usart0_send_buf(char *buf, char len)

{

  u8 i = 0;

  for (i = 0; i < len; i++)

  {

    usart0_send_byte(buf[i]);

  }

}

Modified serial port sending function

void usart0_send_buf(char *buf, char len)

{

  while (*buf != '')

  {

    usart0_send_byte(*buf);

    buf++;

  }

}

Summary: Array initialization and number of elements

1. On the surface, the problem is caused by the non-standard sending function of USART0. The microcontroller runs out of control.

2. Looking deeper, it is the number of elements in the array. If you use the original print function, it is OK as long as the array boundary does not overflow. As shown in the figure below, "rrpc, getimeirn", we think it is 14 bytes, but if the array length is also defined as 14 or only 14 bytes occur, there will be a problem. The compiler prompts that this array needs to prepare 15 bytes of storage space.

3. When sending serial port data in the future, try to use the while (*buf != '') sending method. If you have to use the one-by-one sending method, pay attention to the data boundary to avoid overflow.