Establishing serial communication over UART instead of USB in MAX25405 EVKIT

I was experimenting with the different options on the MAX32620FTHR board to print serial messages. I created some simple code to test behaviour using the latest MbedOS 6.16.

I made life easier and also used a wrapper library, which you would need to import into your project: os.mbed.com/.../

Here is the example code:

/* mbedOS 6.16
 * Board: MAX32620FTHR
 * Copyright (c) C Gerrish
 * SPDX-License-Identifier: Apache-2.0
 */

#include "mbed.h"
#include "BufferedSerial.h"
#include "SerialStream.h"
#include "USBSerial.h"

// Blinking rate in milliseconds
#define BLINKING_RATE       1000ms

#define UART_BAUD_RATE      115200

BufferedSerial fthrUART(P3_1,P3_0, UART_BAUD_RATE);
// This SerialStream is a wrapper for Stream.h to give you printf
SerialStream<BufferedSerial> RXTX(fthrUART);

// true here blocks until USB serial monitor opens
// in Arduino you would use while(!Serial) for same effect
USBSerial USB(true, 0x0b6a, 0x4360, 0x0001);

int main()
{
    // Initialise the digital pin LED1 as an output
    DigitalOut led(LED1);

    int cntr = 0;

    while (true) {
        led = !led;
        ThisThread::sleep_for(BLINKING_RATE);
        USB.printf("hello USB world %d\r\n", cntr);
        RXTX.printf("hello RXTX world %d\r\n", cntr);
        printf("hello DEBUG world %d\r\n", cntr);
        cntr++;
    }
}

The mbed_app.json file:

{
    "target_overrides": {
        "*": {
            "platform.stdio-baud-rate": 115200,
            "platform.stdio-buffered-serial": 1
        }
    }
}

And here is a short video:

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

RE: Establishing serial communication over UART instead of USB in MAX25405 EVKIT

Poster

Upload Preview

Ok

Cancel

[Post EDIT]

Looking at the original MAX25x05 gesture library again to see how the serial part could be adapted to OS6.16 I would say that you could use...

the UnbufferedSerial API for when USE_UART_INTERFACE = 1 as this only provide putc etc.

I've just realised that the above statement is not correct.

In OS6.xx, it is not that simple to use putc anymore. In fact, I think the only way I could find is though the SerialStream wrapper. Not worth the effort, IMHO. If I had read the UnbufferedSerial API documentation more carefully then I would see that it only provides a write function. Sorry about that.

and you could use BufferedSerial API for when USE_UART_INTERFACE = 0 as this provide buffered writes etc.

Hope that helps.

I was thinking about how we could minimise changes in the code, so here is one option that simplifies things.

This code will either print to the debug/console UART pins (as defined in pinNames.h) or to UART pins of choice.

#include "mbed.h"

#define USE_UART_INTERFACE 1

#if USE_UART_INTERFACE
    #define printf(f_, ...) fprintf((f_), __VA_ARGS__);
#else
    #define printf(f_, ...) printf( __VA_ARGS__);
#endif

BufferedSerial otherUART(P3_1,P3_0,MBED_CONF_PLATFORM_STDIO_BAUD_RATE);
FILE* myTX = fdopen(&otherUART, "r+");

// main() runs in its own thread in the OS
int main()
{
    printf(myTX,"Hello New World\r\n");

    while (true) {

    }
}

Are you still using your version of MbedOS?

Just to say that I have managed to get the firmware working with the latest MbedOS 6.16 and have tested it using a Windows laptop with the Maxim GUI software. It all works. I'll post some guidance if you need it. Basically this is cleaner as you do not need to download the separate USBdevice or the MAX32620 libraries. All I had to do was amend a couple of lines in interface.cpp.

So, basically I ignored the UART option as there really is no point using this option when the shield is attached to the MAX32620FTHR board, because you cannot readily get access to the GPIO's unless putting it on a breadboard or soldering wires.

But, if I wanted to use UART in the latest MbedOS 6.16 I would then have to use with BufferedSerial or UnbufferedSerial API and then I would need to amend the code in CMD.cpp as, unlike USBSerial, these API's don't provide printf or getc functions.

He want to do something different. By default firmware communicates with computer over virtual UART over USB. But he do not want this virtual UART. Rather he want real UART. He do not want to comunicate with board from computer but he want use Arduino instead. He correctly found macro which can switch firmware to use real instead of virtual UART but his communication do not work. I am currently out of home so I cant try his firmware but I will do this this weekend.

Do you use any level shifter? What is your connection? Can you post some photo?

I'm using the same version as misaz has used in his mbed CLI. 
I'm using the git commitID 0fdfcf7350896a9c0b57c4a18237677abfe25f1a 

I'm not sure which version it belongs to. But it is the only one that gives no error in compiling the firmware framework provided by Maxim.

My aim is to get the gesture results over UART so that it can be sent to any general MCU like Arduino. 
With the above-mentioned release of mbed, the code works fine for USB so it should work for UART as well as the basic structure of code remains same, only the path where data is sent changes from USB to UART.

Hi! No, I'm not using any level shifter, I assumed that UART is using the standard logic levels. 

Here's my connection diagram -

Baud rate for both the devices is 115200. 

Do you have voltmeter (multimeter)? If yes, try disconnect wires and measure voltage on MAX32620 TX pin. It would be one of 1.8V or 3.3V. What Arduino do you use? ATMega based or some newer ARM Arduino? In case of standard 5V Arduino UNO this connection is dangerous. In case of newer ARM based Arduinos which are usualy powered by 3.3V this connection may be sufficient in case if you measure 3.3V on TX pin.

Ah! I tried multiple arduinos. Uno, Micro and then MKR WAN 1300. Let me do the measurements on the pins. I had completely forgotten that MAX32620 has different voltages then the standard MCUs. I'm reading about 0.8V on the Tx pin of the MAX32620. I'll check the datasheet for the UART logic levels. 

0.8V means pin in High Impedance so this pin is not the output (which TX should be). 0.8V (or any other different than 0V, 1.8V and 3.3V) you should measure on RX pin. On what pin do you measure voltage?

I measured on Tx 0V and Rx 0.8V

Interesting. RX is OK but TX should be in logical 1 when indle but your pin is in logical 0 state for some reason. Does the 0V remains after reset?

Interesting. RX is OK but TX should be in logical 1 when indle but your pin is in logical 0 state for some reason. Does the 0V remains after reset?

Yes Tx remains 0V after reset as well. I'll try some example firmware for UART to check if it works. 

Ok. Currently I am out of ideas which can I provide without having access to real device.

I flashed the board with the code provided by BigG now I read 1.3V on Rx (as written on the PCB of MCU) and 0V on Tx pin (as written on the MCU PCB). I think the interpretation of Tx and Rx could be different on Maxim boards. 

Btw what pin exactly do you use as TX and RX? MAX32620 supports four UARTs. Do you use pins expossed on shield on JP5 or do you connect directly to some pinheader of FTHR board?

No issues. I'll try some more methods to check the UART. Let me know if you succeed with this over the weekend. 

The code in the framework has defined pins P3_0 and P3_1 as UART pins.  

#if USE_UART_INTERFACE
Serial *serial = new Serial(P3_1,P3_0,UART_BAUD_RATE);

I'm using the same pins connecting wires directly to the pin headers of P3_1 and P3_0

It is the same behaviour. 1.3V is the same as 0.8V. RX pin is input. MAX32620 set this pin as input which means that it do not connect this pin directly to GND (0V) or VDDIO(H) (1.8 or 3.3V depending on fimrware selection). Because pin is virtualy disconnected there theoreticaly is only voltage provided externaly like noise, inducted voltage from your body, signal from aliens and so on. Practicaly this voltage come also from implementation of digital logic.

Yes. Pins 3.0 and 3.1 should be correct. These pins are also routed to shield to JP5.