Establishing serial communication over UART instead of USB in MAX25405 EVKIT

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.

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.

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. 

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.

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.

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. 

misaz rsjawale24 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.

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.

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

Don't let the quantity of code put you off. The algorithms are actually fairly straightforward. It's just a little messy that's all, probably because the code has not been worked on and refined.

So, basically the code captures an array of data from the sensor (using either SPI or I2C), then it averages things out for you using a sort of moving average (as in averages out 3 data arrays) and then it does some filtering of the data to extract out background noise using another 2 data arrays and a min and max value, so that it can detect the gesture.

It then has some code that determines if it detects movement in progress or the movement has stopped (I haven't figured out how it does this part). It also prints out the data.

The user command part is just for the windows GUI software.

As such, regardless of algorithm & user command, you are still left with 6 rows of data containing 10 values each. You will still have to use that data to determine the gesture.

I am getting near... Here is stack trace of location in which our firmware stuck after executing poll command. mbed_halt_system has infinite loop in which program stuck. Stuck is consequence of some hard fault.

I found quick (but not reliable answer): Change compiler. If you use gcc bundled in Debian instead ARM compiler which I recommended, then It generates more compact image which works But I will still dig into it and try find solution working with any compiler if possible.

Today I found root cause of the issue. Issue is caused by invalid assembly code generated by modern ARM compiler. With older GCC compiler it works because it handle undefined behaviour used in code differently. I will write (long) blog with more details describing what exactly happended on Cortex-M4 core including all details about my analysis, listings of faulty assembly code and (lot of) details about debugging procedure which I applied to finding root cause of issue.

TLDR solution for our problem is following.

1. Open cmd.cpp
2. Go to function cmd_poll at line 269
3. Add return CMD_ACK; to the end of the function
4. Recompile, enter bootloader, drag and drop new firmware and MCU will not crash after poll command anymore.

The missing return statement cost me about 7 hours of debugging....

Today I found root cause of the issue. Issue is caused by invalid assembly code generated by modern ARM compiler. With older GCC compiler it works because it handle undefined behaviour used in code differently. I will write (long) blog with more details describing what exactly happended on Cortex-M4 core including all details about my analysis, listings of faulty assembly code and (lot of) details about debugging procedure which I applied to finding root cause of issue.

TLDR solution for our problem is following.

1. Open cmd.cpp
2. Go to function cmd_poll at line 269
3. Add return CMD_ACK; to the end of the function
4. Recompile, enter bootloader, drag and drop new firmware and MCU will not crash after poll command anymore.

The missing return statement cost me about 7 hours of debugging....

I was getting error that function is not void so it should return something. I just put return 0 there and it compiled successfully. However return 0 will only return 0 after successful execution. How come I didn't think of this!!

Thanks for the help. I'll try it asap

This function should return 0 allways.

Then just adding return 0 should also work!!

I'll try it and will post her

Wow, great spot (re Add return CMD_ACK; )

It's worth noting that the poll command is lacking the actual gesture result, as you see in the default demo binary.

In the poll command all it provides is a placeholder (gesResult.int_placeholder,)

Also, if you look in gesture_lib.h you will see the gestureEvent enum only provides a template:

/*
* Enumerate gesture events here
*/
typedef enum {
    GEST_NONE,
    GEST_PLACEHOLDER
} GestureEvent;

No doubt there is a bunch of code in that demo binary to adds in all the gestures.

As far I did not fix any code logic. I just ensured that code do not crash.

As far as I can work out I think it requires a major piece of work to get the MCU to recognise different gestures.

The poll command was returning all 0'z and then crashing. It seems now it won't crash but the result will still be 0's if there is logic problem. 

Yes that's correct. So at least the crash has been sorted but some way to go to now get real answers.

great work digging out the root cause

If someone is interested, today I published blog with detials about debugging:  Blog #7: Debugging Maxim’s Firmware Framework Crash