Conflicts between USB and IO modules vs M5 libraries

[K7MDL2]

I have managed to see the 4-In/8-Out and the USB Host modules work with a Core3-Se finally, using the examples. Am using the M5Core3.h lib. If USB and IO stay stable, I may add the BLE code to the existing BT Classic and shift to the Core3. I ordered a Core2 to test with.

1. I have run into a challenge getting the USB host v1.2 module to work the M5Unified library. It works with M5Stack lib (sometimes). I think it works best with no M5 lib. For reasons I cannot pin down the USB host may lock up after a minute or less, or it can run forever I have seen it run days but some seemingly unrelated changes I go to test USB and it does not work right anymore. I am thinking it has something to do with the FREERTOS underneath TinyUSB lib. The example do not use any M5Stack or M5Unified lib. I have older and newer versions of the full program, the older one works, but have not identified why, they look identical. Reminds me of the ancient days when non-printable characters in the editor broke builds.

2. The IO module does not seem to work with the M5Stack, thus the need to move to the M5Unified lib, which then breaks USB Host. Like the USB, the examples do not use the M5xxx libs.

Maybe can skip the M5xxx libs and get graphics through another lib like M5GFX.h. This has been frustrating and time consuming to nail down. The Core2/3 may be an exit plan if they work.

[K7MDL2]

More testing, no final conclusion yet. Dealing with the USBHost issue first. I was able to get the USB Host working well on the Core Basic using the M5Stack lib.

Further I put the buttons and app loop into FreeRTOS tasks joining the USBHost.task. Changed all delay() to vTaskDelay(). Added in some defines for CoreS3 to switch I2C and SPI pins and the M5.begin()/M5.Power(). The newer libs use auto cfg = M5.config() + M5.begin(cfg).

Put some stack size probes in and adjusted each stack size to give at least 2000 words extra from the lowest free space I observed during run time. If any task gets below 1000 words free stack space a very noticeable debug line will print on the serial.

I can switch freely between BT and USBHost no problem so far. I disconnect BT (not end it) when switching to host. Further new logic will force a radio address search when the search button is pressed. Switching modes will use the last address used if 'auto_address' var is set to 0. 1 forces a new search in every condition.

I observed the polling rates in and outside of the RTOS task and tweaked some delays, generally reducing them to minimal values. Some printouts staged will show a visual timely for each scheduling. The major reason for moving the main app loop to a RTOS task is because I observed:

1. The main loop would stop updating after several seconds. Disconnect the USB plug and it responds as expected, which is to print disconnect message and reboot.
2. When USBHost was the only task running as a task, RTOS watchdog timed out and rebooted. Depending on library chosen and other factors it would just hang like above, or timeout and reboot. No idea why but decided to put everything in a task and begin splitting things up and timing them.
3. This USB hang situation has come and gone over time with seemingly unrelated changes elsewhere, now I believe it is partly (mostly) due to changing libraries to M5Unified or M5Core3 and using BT mode without checking on USB mode and realizing it was broke. It is set up now I can better see what each task is doing.
4. Part of the reason for changing libraries was to see if a common library would work for all CPU models and for the IO and USB modules I have. So far I have not found a universal answer. I have a test program for all of these and I do not think I found a magic combo yet. Right now with USB Host working the M5Stack lib, the 4-In/8out module is not working. Fails on i2c bus - fail to request a lock. It does work on the other libs. Will have to dig into the M5Stack lib/Wire.h and see if the I2C pin assignments work right.

In summary, compatibility seems a bit of a mess. I miss my Teensy4 world.

[K7MDL2]

Made further progress. Can run USB Host on the Core2 with the M5Core2.h and get USB to run as long as the Basic. M5Unified.h kills off USB Host promptly. Talking over i2c to the IO module kills off USB Host, hangs the process. Modified the pins assignments in the USB host library, no change.

USB Host works OK on an early version of the program before the graphics and IO module were added. Given how M5.Unified acts so different than M5Core2.h, it feels like the CS and INT pins may not be handled correctly as they are different for each model.

I do not think the CoreS3 talks to the IO module or runs I2C scan, but I can see the factory program scan the I2C bus OK.

[K7MDL2]

Now have the CoreS3, Core2 and Core Basic all working with the IO module, SD card, graphics and partly, buttons (of various methods).

All of these CPUs models fail to operate with the USB V1.2 module when there is any IO and graphics activity. The FreeRTOS USB Host task appears to be alive in some part evidenced by pulling the USB cable out and the disconnect event fires off. However the app_loop and main loop appear halted or hung.

My working assumption is a broken or missed event related to SPI communications. I would not be surprised if it was using the wrong pins at times, or worse, not managing access to SPI bus, possibly busting other process's SPI operations putting them into a wait state. There may be USB data there, but no way to extract it.

USB Host works on an older version of code before IO module or graphics. Add either, and things hang in short order. The fact it can work for a random time further suggests it is a SPI bus timing/access issue.

[K7MDL2]

Found that USBHost will run for a very long time, over a day, IF I run it in the foreground with no optional timeout parameters. It will respond to radio side issued messages and let the main loop run one time so the display gets updated, but then after all other functions are blocked - buttons, polling. If I add a timeout, say 5ms, or 1ms, it will let the main loop run every 5 or 1ms one time. It eventually hangs. It makes sense it would do this waiting for events if it was run as a task in FreeRTOS, but that always results in a lockup in short order when combined with other things like graphics and IO. Tried different SPI bus frequency settings, no improvement.