Actions
Forum Thread Details
  • Replies 89 replies
  • Subscribers 41 subscribers
  • Views 10304 views
  • Users 0 members are here
Related

Establishing serial communication over UART instead of USB in MAX25405 EVKIT

rsjawale24

The MAX25405EVKIT comes with a MAX32620FTHR board which is preprogrammed with custom binary file for the gesture recognition. The application note at Maxim Gesture Sensor EVKit Serial API (maximintegrated.com)

mentions "The serial interface can be implemented over the Universal Serial Bus (USB) virtual serial port or over a Universal Asynchronous Receiver-Transmitter (UART). The EV kit is shipped configured to use the USB serial port to work with the EV kit PC Graphical user Interface (GUI). If a UART serial interface is desired, custom firmware in binary format is available."

Upon researching more, I found the firmware_framework code that contains the code for gesture recognition compiled using mbed compiler.

The readme file says that a file called interface.h and interface.c define the communication protocol. When I open the interface.c file, I can see a comment in the code that says Option to implement serial API over UART instead of USB but there is only a MACRO set as #define macro_name 0 

I tried to change the 0 to 1 and compile the code, however, it does not compile successfully. The USBDevice library shows some error while compiling. 

Did anyone try to change the serial API over UART instead of USB? Was it successful?  

EDIT: I have successfully compiled the code for UART. However, I'll do some experiments and write introductory blogs before I re-program the MAX32620FTHR board with my firmware. 

Parents

  • So I'm facing another problem now.

    As long as I send commands like ver and ping, it works fine. But as soon as I send poll command, I get results and then it gets stuck there. It does not respond to any commands. Not sure why this is happening.

  • in reply to rsjawale24

    I also noticed this behaviour. I had not very much time, so following information about source code and my theory may be inaccurate. After brief look to code I did not find anything which should cause crash of firmware. Executing poll command only printf some data from global variables if I understand it correctly. But I remember that readme.txt contained some notices of extending main stack nad poll printf is quite a complicated (memory usage extensive). Maybe our firmware was not compiled and configured properly and printf with many format strings make some memory overflow which destroys stack and causes firmware to crash. I will try to debug it this week and find some fix.

Reply
  • in reply to rsjawale24

    I also noticed this behaviour. I had not very much time, so following information about source code and my theory may be inaccurate. After brief look to code I did not find anything which should cause crash of firmware. Executing poll command only printf some data from global variables if I understand it correctly. But I remember that readme.txt contained some notices of extending main stack nad poll printf is quite a complicated (memory usage extensive). Maybe our firmware was not compiled and configured properly and printf with many format strings make some memory overflow which destroys stack and causes firmware to crash. I will try to debug it this week and find some fix.

Children