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.

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

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.

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