Actions
Forum Thread Details
  • Replies 89 replies
  • Subscribers 41 subscribers
  • Views 9039 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 Reply Children
  • 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.

  • in reply to misaz

    Thanks! I looked into it. The poll command is giving only 0's as output so maybe something is wrong. I will try looking into in tonight. 

  • in reply to rsjawale24

    I've create a very basic stripped down library based on the firmware framework using the latest MbedOS 6.16.

    github.com/.../Max25x05_MbedOS6

    All it is doing is getting the raw pixel data. It is doing none of the manipulation routines as yet.

    It seems to provide data and does not lock up using USBserial - well OK, I only let the program run for about 20 seconds. You should be able to change USBSerial and use RX/TX pins.

    Please let me know if you spot any errors, or have any problems, and you are free to recommend changes.

    At the moment, the only thing that is puzzling me is the configuration setting used in the Firmware Framework for MAIN CONFIGURATION 2 (0x2). Here the value is set to 0x02 and this does not correspond with the documentation.

    Maybe someone has an answer.

  • in reply to BigG

    Thanks, I'll check this. But the gesture algorithm is quite complex, I guess. Here from the raw pixel data it would be difficult to identify the gestures, or maybe a simple gesture sensing algorithm can be devised by reading the raw sensor data. 

  • in reply to rsjawale24

    Yep, it is quite complex but I'm trying to simplify the code so that it is easier to understand, and also hopefully, to make sure it does not lock up. At least for now, I know that the sensor can be read and the raw values can be printed without glitching.

  • in reply to BigG

    Almost everything can be done without glitching on MCU clocked at 96 MHz (96 000 000 clock cylces per second) with 256 KiB (262 144 bytes) RAM. There is some more significant issue with the firmware. I think it is easier to fix Maxim firmware in this case. I packed up MAX32620FTHR this weak but I forgot to pack up PICO board for debugging, so I will debug it later this weekend.

  • in reply to BigG

    Yes, the issue is not with the hardware so it should not lock up the program while reading. The problem lies in the firmware code provided by Maxim. Which currently, I'm unable to determine. 

  • in reply to misaz

      Oops maybe a poor choice of words used... I meant glitching in the broadest sense (dictionary def: suffer a sudden malfunction or fault) and took it as software/firmware related.

    In my experience you need a debugger to catch these errors and when you're not the author of the code it becomes rather difficult to work out the problem. As such, I have found my personal preference, as it works for me, is to recreate or repack the code function by function to fathom out what's going on.

    The code is certainly a little messy for my liking. Now that I've spent a bit of time on this, I have determined (so far) that there are at least 6 pixel arrays (each size 60 of integer or float data type) which are storing pixel data plus the different data structures. So yes it uses a fair bit of memory.

  • in reply to BigG

    I understand. I am not good in english so maybe I misunderstand your previous post.

    Repacking and simplifing project is good idea, but I will still try to debug code rather. My theory is that it crashes to some HardFault handler so it should not be so hard to debug. But who knows? I did not try it yet.

  • in reply to BigG

    I'm not very good at coding..all I can do is write simple programs and understand codes. But when it comes to writing codes for such complex devices, I'm not very good at that. I will try debugging..I have ordered a Maxim Pico and I should recieve it soon. However, I don't know how to debug.

    Also while compiling the code, I noticed there were tons of warnings being generated. Maybe some of the warnings are critical and are affecting the firmware working.

    Its really great that you're working on your own code!

    Also another thing to note which I just remembered the maxim firmware only locks up when you send the poll command, it does not lock up for other commands no matter how many times you send them.

    So this could be some kind of data overloading not sure. Let's try debugging. I'll need some help with that though