SDLauncher: M5Stack core gray + SD <=> LoRa 868 RA-01H bus sharing conflicts

[ifrew]

Updated to the latest build of esp32 for Ardunio last week, web site says 2.0.3 but the platforms.txt file says its 2.0.4. Updated to your latest Updater today. Compiled the menu.bin program and flashed to m5stack. First time it worked, hitting the power reset it sort of worked and after each reset I will see the main menu with no files, or some files without the icons but selecting them won't load. Diving in deeper I'm seeing a bunch of sd card read warnings and errors. see output from console below. Looking at esp32 github for SD issues I cant seen to find many but I did see your name appear in a couple of issues that seem to be related. Are you seeing the same issues or is there a workaround available that you know of? I've checked that the sd cards are not corrupted and tried different types. Pretty sure is a SD library or SPI issue. I'm using Visual Studio with VMicro...Thanks Iain

rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff0030,len:1344 load:0x40078000,len:13732 ho 0 tail 12 room 4 load:0x40080400,len:3608 entry 0x400805f0 [ 1][D][Button.cpp:42] Button(): Button on pin 39, invert=1, debounce=10ms [ 1][D][Button.cpp:42] Button(): Button on pin 38, invert=1, debounce=10ms [ 4][D][Button.cpp:42] Button(): Button on ��� 37, invert=1, debounce=10ms [ 12][D][esp32-hal-cpu.c:214] setCpuFrequencyMhz(): PLL: 480 / 2 = 240 Mhz, APB: 80000000 Hz ESP32-Chimera-Core initializing [Board=M5Stack_Core_ESP32] [Variant=m5stack_core_esp32] [ 86][D][ESP32-Chimera-Core.cpp:93] begin(): Enabling LCD [ 100][W][LGFX_AutoDetect_ESP32.hpp:415] _read_panel_id(): [LovyanGFX] [Autodetect] read cmd:04 = 000000e3 [ 101][W][LGFX_AutoDetect_ESP32.hpp:1237] autodetect(): [LovyanGFX] [Autodetect] M5Stack [ 257][D][ESP32-Chimera-Core.cpp:276] sd_begin(): Enabling SD from TFCARD_CS_PIN #4 at 25000000 Hz from core #1 ESP32-Chimera-Core started [ 290][D][M5StackUpdater.h:211] _fsBegin(): Checking for SD Support (pin #4) [ 291][D][M5StackUpdater.h:217] _fsBegin(): SD Successfully mounted (pin #4) [ 296][I][esp32-hal-i2c-slave.c:234] i2cSlaveInit(): Initialising I2C Slave: sda=22 scl=22 freq=100000, addr=0x15 [ 306][D][esp32-hal-i2c-slave.c:498] i2c_slave_set_frequency(): Fifo thresholds: rx_fifo_full = 28, tx_fifo_empty = 4 [ 316][E][Wire.cpp:260] getClock(): Bus is in Slave Mode [ 321][E][Wire.cpp:308] beginTransmission(): Bus is in Slave Mode [ 327][E][Wire.cpp:331] endTransmission(): Bus is in Slave Mode [ 333][E][Wire.cpp:260] getClock(): Bus is in Slave Mode Welcome to the M5Stack SD Menu Loader! M5Stack SD Updater initializing... M5StackSam loaded with 8 labels per page, max 96 items Has PSRam: false [ 359][I][menu.h:148] heapState(): RAM SIZE: 333.84 KB FREE RAM: 264.15 KB MAX ALLOC: 107.99 KB [ 403][W][menu.h:658] checkMenuTimeStamp(): Menu.bin has an obsolete time set (2022-06-03 11:14:12), will use this sketch build date to set the clock

[Hobo style] Clock set to an obsolete source (this sketch build): June 03 2022 13:36:24 (Friday) [ 454][I][menu.h:386] listDir(): Listing directory: /

[ 455][D][menu.h:399] listDir(): DIR : /cert [ 455][D][menu.h:399] listDir(): DIR : /data [ 457][D][menu.h:399] listDir(): DIR : /.registry [ 462][D][menu.h:399] listDir(): DIR : /bmp [ 467][D][menu.h:399] listDir(): DIR : /mod [ 471][D][menu.h:399] listDir(): DIR : /System Volume Information [ 477][D][menu.h:399] listDir(): DIR : /mp3 [ 482][D][menu.h:425] listDir(): IGNORED FILE: /tetris.jpg [ 487][D][menu.h:399] listDir(): DIR : /jpg [ 492][D][menu.h:399] listDir(): DIR : /json [ 496][D][menu.h:425] listDir(): IGNORED FILE: /buddies.txt [ 1001][W][sd_diskio.cpp:174] sdCommand(): no token received [ 1100][W][sd_diskio.cpp:180] sdCommand(): crc error [ 1200][W][sd_diskio.cpp:180] sdCommand(): crc error [ 1300][W][sd_diskio.cpp:180] sdCommand(): crc error [ 1400][W][sd_diskio.cpp:180] sdCommand(): crc error [ 1501][W][sd_diskio.cpp:180] sdCommand(): crc error [ 1600][W][sd_diskio.cpp:180] sdCommand(): crc error [ 1700][W][sd_diskio.cpp:180] sdCommand(): crc error [ 1800][W][sd_diskio.cpp:186] sdCommand(): token error [17] 0x54 [ 1801][W][sd_diskio.cpp:180] sdCommand(): crc error [ 1900][W][sd_diskio.cpp:180] sdCommand(): crc error [ 2000][W][sd_diskio.cpp:180] sdCommand(): crc error [ 2100][W][sd_diskio.cpp:180] sdCommand(): crc error [ 2200][W][sd_diskio.cpp:180] sdCommand(): crc error [ 2300][W][menu.h:444] listDir(): [WARNING] No /menu.bin file found

[ 2301][W][sd_diskio.cpp:180] sdCommand(): crc error [ 2400][W][sd_diskio.cpp:186] sdCommand(): token error [13] 0x76 [ 2400][E][sd_diskio.cpp:621] ff_sd_status(): Check status failed [ 2406][I][menu.h:386] listDir(): Listing directory: /

[ 2406][W][sd_diskio.cpp:186] sdCommand(): token error [13] 0x17 [ 2412][E][sd_diskio.cpp:621] ff_sd_status(): Check status failed [ 2418][W][sd_diskio.cpp:180] sdCommand(): crc error [ 2522][E][vfs_api.cpp:293] VFSFileImpl(): opendir(/sd/) failed [ 2522][E][menu.h:389] listDir(): Failed to open directory [ 2583][W][sd_diskio.cpp:180] sdCommand(): crc error [ 2683][D][fsformat.h:165] hasMeta(): [JSON]: no currentMetaFile /json/.json [ 2683][I][menu.h:148] heapState(): RAM SIZE: 333.70 KB FREE RAM: 262.97 KB MAX ALLOC: 107.99 KB

[tobozo]

hey @ifrew thanks for your feedback

I just did a test using 2.0.3-RC1 (which is known to have problems with SD) and 2.0.3 (which fixes SD problems) on my old M5Stack Classic (the one with 4MB flash) and I get a correct file listing in both situations.

These are the settings I've used to flash the sketch:

I'll need mode information on your configuration in order to reproduce the issue you're describing.

However, in the logs you provided, the init sequence claims the SD Card is correctly mounted:

[ 257][D][ESP32-Chimera-Core.cpp:276] sd_begin(): Enabling SD from TFCARD_CS_PIN 4 at 25000000 Hz from core 1
ESP32-Chimera-Core started
[ 290][D][M5StackUpdater.h:211] _fsBegin(): Checking for SD Support (pin 4)
[ 291][D][M5StackUpdater.h:217] _fsBegin(): SD Successfully mounted (pin 4)

Here's a checklist:

1) Remove the M5 bottom and any attached sensor, only keep the USB cable, and try again, does it still fail ? 2) Scandisk/repair the SD Card from a PC/Mac 3) Try with a different model of SD Card

if none of those work, then I'll need much more information about the situation e.g. exact model of m5stack, OS version, arduino version, all librarires versions, sd card model, partition size, files count, etc, etc

[tobozo]

Some random observations I've made during the bug hunt with SD driver:

Firmwares compiled with a different version of the SD driver may no play well together.

e.g. flashing a binary compiled with espressif package 1.0.6 from a launcher compiled with espressif package 2.0.3 will cause problems with partition size and incomplete SPI init sequence.

There's also an edge case with platformio+espressif package 2.0.1 that bricks the M5 when any pre-1.0.6 binary is loaded, the resulting crash loop is so fast that even flashing becomes a challenge :-) Fortunately this version isn't referenced anymore by plaformio so it doens't have to be supported, but the situation still exists.

Troubleshooting

Whenever something odd happens, you should always power-cycle the M5 + eject/reinsert the SD Card, to confirm that the issue is persistent and not a consequence of a previous bootloader conflict between mismatched espressif packages.

The reason of this behaviour is because at some stage of the recent SPI changes, the SD Driver adopted an inverted logic towards the CS pin. As a consequence when sd-updating from a binary compiled with 1.0.6 to a binary compiled with a more recent version, the loaded binary will keep the pin state from the previous runtime.

Moreover, if a sd-loadable application needs to write on the SD Card after this type of error, corruption may occur. So every test made right after a scandisk/repair should exclude any sd-loaded application that writes on the SD-Card in order to be valid!

This is why ejecting / power-cycling / reinserting is sometimes necessary to confirm the issue is in the code and not a consequence of a cold-boot conflict.

Custom boards URLs

Make sure you're using the official package URL in Arduino preferences (Additional Boards Manager URLs) and not the one from M5Stack which appears to lag behind and may be bundled with an old version of the SD Driver.

[ifrew]

Thanks for the quick reply! It's early here in Seattle but I followed your troubleshooting tips.

I had already made a couple of changes to my esp32 core to try and fix it after finding and reading issues related to the SD driver in github namely bug numbers 6103 and commenting out the 2 lines referenced in 6081 but they didn't help.

When the device is first flashed it always works. However, if you reset the power button a few times, after the 3rd time things start going wrong.

My application that uses the SD card and another spi device sensor as well as the display works fine reading and writing to the SD card so I had assumed it was a problem with the latest builds for esp32 for Arduino and your code. However, I hadn't thought to try your code without my spi sensor.

So I flashed another device I have here without the sensor and your code works perfectly even loading my code and subsequently using the A button to restart and load your code. I did it multiple times .

So my issue with your code is due to conflicts of using another spi device in the mix.

Interestingly though, I haven't had any issues reading or writing to the SD card from my app, at least yet.

If I erase the m5stack completely and reflash my app, without first flashing yours, and then install yours from my app using the A button and loading menu.bin that's when things go wrong when I have the other spi device attached.

Without the other spi device it works a treat.

My other spi device uses the HSPI bus so seems I have an SPI issue with persistency issues. Hmm... going to have to think about this. If you want, I'll leave this open for now in case other people have similar issues until I find the problem. If you want me to close it let me know. Thanks!

[tobozo]

sorry I edited your comment for readability :-)

If I understand correctly, the SD-Updater functionality is unaffected by this situation, and only the SD-Launcher shows problems listing the content of the SD Card when the SPI has been shared before a soft reset ?

One thing you may experiment with is to add this macro before #include <ESP32-Chimera-Core.h>:

#define TFCARD_USE_WIRE1
#define TFCARD_SPI_HOST SPI_HOST // or VSPI_HOST

this will attach the SPI from SD to the M5 object and expose it after M5.begin() as:

  (SPIClass *) M5.SD_SPI;

so you can eventually share it with your external SPI device, provided they have separate CS pins.

[ifrew]

Yes, the SD-Launcher shows problems listing the content. I edited the M5STACk-SD-MENU source to put in the lines above in the core.h file. I'm assuming you mean for me to edit your example as I don't use the ESP32_Chimera_core library. That causes an exception when flashed to a stand alone m5stack module either using SPi or VSPI. I erased the device completely before flashing. The esp-decoder funnily enough doesn't seem to show the full stack. See below. Could you explain your thought process here. I'm not quite clear on why I'm having an SPI sharing issue when having my code and your code flashed to the device after a soft reset. And a correction, I thought I was using the HSPI bus for my sensor, I'm not its the same VSPI bus. When I switched to using the HSPI bus I got no display in my app but was able to load the menu.bin file when using button A but I got the same issue on soft resets not being able to see contents of sdcard properly,. I'm not sure how the SPI sharing in your app is conflicting with mine so any insights may help me get to the bottom of this.

Rebooting... ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff0030,len:1344 load:0x40078000,len:13732 ho 0 tail 12 room 4 load:0x40080400,len:3608 entry 0x400805f0 [ 1][D][Button.cpp:42] Button(): Button on pin 39, invert=1, debounce=10ms [ 1][D][Button.cpp:42] Button(): Button on pin 38, invert=1, debounce=10ms [ 4][D][Button.cpp:42] Button(): Button on ��� 37, invert=1, debounce=10ms [ 12][D][esp32-hal-cpu.c:214] setCpuFrequencyMhz(): PLL: 480 / 2 = 240 MESP32-Chimera-Core initializing [Board=M5Stack_Core_ESP32] [Variant=m5stack_core_esp32] [ 79][D][ESP32-Chimera-Core.cpp:93] begin(): Enabling LCD [ 93][W][LGFX_AutoDetect_ESP32.hpp:415] _read_panel_id(): [LovyanGFX] [Autodetect] read cmd:04 = 000000e3 [ 94][W][LGFX_AutoDetect_ESP32.hpp:1237] autodetect(): [LovyanGFX] [Autodetect] M5Stack [ 250][D][ESP32-Chimera-Core.cpp:276] sd_begin(): Enabling SD from TFCARD_CS_PIN #4 at 25000000 Hz from core #1 ESP32-Chimera-Core started ESP-IDF version is: v4.4.1-1-gb8050b365e [ 269][D][M5StackUpdater.h:211] _fsBegin(): Checking for SD Support (pin #4) [ 269][D][M5StackUpdater.h:217] _fsBegin(): SD Successfully mounted (pin #4) [ 275][I][esp32-hal-i2c-slave.c:234] i2cSlaveInit(): Initialising I2C Slave: sda=22 scl=22 freq=100000, addr=0x15 [ 286][D][esp32-hal-i2c-slave.c:498] i2c_slave_set_frequency(): Fifo thresholds: rx_fifo_full = 28, tx_fifo_empty = 4 [ 296][E][Wire.cpp:260] getClock(): Bus is in Slave Mode [ 301][E][Wire.cpp:308] beginTransmission(): Bus is in Slave Mode [ 307][E][Wire.cpp:331] endTransmission(): Bus is in Slave Mode [ 313][E][Wire.cpp:260] getClock(): Bus is in Slave Mode Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.

Core 1 register dump: PC : 0x400d66d6 PS : 0x00060a30 A0 : 0x800d9829 A1 : 0x3ffb2760
A2 : 0x3ffc237c A3 : 0x00000000 A4 : 0x3ffc1a80 A5 : 0x3ffc32c4
A6 : 0x3f4002e4 A7 : 0x3ffbdc0c A8 : 0x800d66c6 A9 : 0x3ffb2740
A10 : 0x3ffb28b8 A11 : 0x3f4008f6 A12 : 0x0000003f A13 : 0x00000051
A14 : 0x3f400381 A15 : 0x00000004 SAR : 0x00000004 EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000010 LBEG : 0x40088f51 LEND : 0x40088f61 LCOUNT : 0xfffffffe

Backtrace:0x400d66d3:0x3ffb27600x400d9826:0x3ffb27c0 0x400f2f12:0x3ffb2820

and the decoding

Decoding stack results 0x400d6831: UISetup() at d:\documents\arduino\libraries\lovyangfx-master\src\lgfx\v1/panel.hpp line 101 0x400d9be6: setup() at C:\Users\Ifrew\AppData\Local\Temp\VMBuilds\M5Stack-SD-Menu\espressif_m5stack-core-esp32\Release\main/main.cpp line 14 0x400f4b92: loopTask(void*) at D:\Documents\Arduino\hardware\espressif\esp32\cores\esp32\main.cpp line 42

[tobozo]

found this in an unrelated sketch:

    SD.end(); // If not Bluetooth doesn't work !!!

although you're obviously not concerned by bluetooth, this is still an interesting lead to follow up on

SDUpdater doesn't perform a SD.end() since the SD driver is supposed to reset the SPI and CS pin state when the bootloader is called, but maybe it should

one way to check that (provided you're using updateFromFS()) is to insert SD.end() in your LoRa sketch between updateFromFS() and ESP.restart()

another way to check that (choose one but don't test both together) is to start SD twice on boot from the SD-Menu app:

M5.begin();
SD.end();
M5.sd_begin();

[tobozo]

(sorry about the spam)

found a SO post somehow related because it demonstrates how to properly share the SPI bus between LoRa and SD

https://arduino.stackexchange.com/questions/69927/sd-card-and-lora-module-arduino-uno

apparently all spi-based M5 LoRa modules are sharing the SPI bus with the SD module, so it becomes a fromage ou dessert situation where you can talk to either module but not both, plus you need to make that as a transaction.

this is roughly what should happen:

void loop()
{

  digitalWrite( LORA_CS_PIN, LOW );    //  SELECT LoRa SPI 
  SPI.begin();
  // talk to the LoRa module
  SPI.end();
  digitalWrite( LORA_CS_PIN, HIGH );   //  DESELECT LoRa SPI   

  digitalWrite( TFCARD_CS_PIN, LOW );  //  SELECT SD Card SPI
  SPI.begin();  // or SD.begin()
  // talk to the SD module
  SPI.end();  // or SD.end()
  digitalWrite( TFCARD_CS_PIN, HIGH ); //  DESELECT SD Card SPI

  delay(500);
}

also note that both should be deselected before the ESP restarts, since SD-Menu isn't LoRa aware it can't guess what CS pins to reset, and this may leave your LoRa module in the last state it was before the restart, thus sending unsollicited data across the SPI bus.

in order to prevent this you need to take care of it from your LoRa sketch.

void setup()
{
    // before calling M5.begin()
    digitalWrite( LORA_CS_PIN, HIGH );   //  DESELECT LoRa SPI 
    M5.Begin();
    // checkSDUpdater( ... params ... ); // before enabling LoRa
    LoRa.begin();
    // ( ... )
}

// if you sdupdater implementation uses a UI option rather than button push at boot
void onLoadMenuBin()
{
  digitalWrite( LORA_CS_PIN, HIGH );   //  DESELECT LoRa SPI 
  SD.begin(TFCARD_CS_PIN);
  updateFromFS(SD);
  SD.end();
  ESP.restart();
}

[ifrew]

Thanks for that info! I've spent all day trying to get it working, but unsuccessful. However, I'm pretty sure I know what the problem is but my skills unravelling inherited classes and debugging is getting rusty these days,!.

I tried for a few hours and things got a little better and a little worse enabling and disabling the control signal for the lora module I use before accessing the sd card. However, It occurred to me that my own app reads and writes to the SD card , the M5stack display and talks to Lora didn't have any issues.

So I started looking at your example m5stack-sd-menu code. The difference between your example and my code is that I use the TFT_ESPI library and you use the LGFX library. You have autodetect set, and looking into the library code, I see that it tries to detect a whole bunch of different boards before finding the m5stack.

During that search, some of the boards are using the same Pin I use for the Lora control signal on the SPI bus and the library has its own low level way of talking to the SPI bus. I tried to change the library by moving my board to the top so it was found first but that didn't fix the problem.

However there is quite a lot of low level code in there. I tried to then change your example to use the TFT_ESPI graphics library but I got myself into a real mess. I still had the original copy of your sdupdate and examples that used the M5STACK graphic library and I' now have that version working again without any issues.

So I expect that the issue is that the LGFX graphics library potentially can cause issues with SPI devices if the pins on the boards it is searching conflicts with the CS pins of other SPI devices.

Thanks for your help on this. Much appreciated.

[tobozo]

thanks for your research, very interesting.

I have notified @lovyan03 about the pin conflict LGFX_AUTODETECT is possibly creating.

There are a few different M5 LoRa modules out there, and not all of them use the same pinout,

Can you speficy what exact model you're using? (or the pinout if you have built your own shield)

[edit] at this point it may be a good idea to share your project source

[tobozo]

still researching, so far I found your post from two years ago and I will assume this is the hardware you're using unless you say otherwise.

also after speaking with lovyan03, we haven't been able to confirm the issue is coming from the auto detect routine, this means ESP32-Chimera-Core, M5StackUpdater, and the SD-Menu itself are still in the scope of the bug hunt.

meanwhile @kongduino (thanks!) has shared this two years old M5_LoRa_GeoLoc project where SD and LoRa coexist without conflicts.

M5_LoRa_GeoLoc uses chimera-core, so adding checkSDUpdater() in the setup should be enough to reproduce the same error-conditions you get in the SD-Menu after hot-loading menu.bin from your LoRa sketch.

it needs a GPS module on the grove port and a registered mapquest key to work though, if you have such module it would be interesting to observe the results.

[ifrew]

Thanks for the additional info on sdupdater working with chimera code. Yes, I use the the M5stack lora 868 module together with a gps and an i2c pressure sensor on a custom board but they don't use SPI, only serial and i2c pins of the M5stack module. I'll look at the example you referenced to see the differences.

[edit] I tried to get the m5_lora_geoloc project compiled but couldn't. There are a few libraries and include files missing from the build. The lora part I can change and configure to use mine easily. However, they also use the M5Stack core2 which is a different device from the one I use.

[tobozo]

I'm not sure it's propagated yet, but I pushed a fix on Chimera-Core and released a new version.

The I2C was improperly started in slave mode, so it should at least solve the sda=22 scl=22 WTF in the boot log (although it probably won't affect this issue):

[ 296][I][esp32-hal-i2c-slave.c:234] i2cSlaveInit(): Initialising I2C Slave: sda=22 scl=22 freq=100000, addr=0x15
[ 306][D][esp32-hal-i2c-slave.c:498] i2c_slave_set_frequency(): Fifo thresholds: rx_fifo_full = 28, tx_fifo_empty = 4
[ 316][E][Wire.cpp:260] getClock(): Bus is in Slave Mode
[ 321][E][Wire.cpp:308] beginTransmission(): Bus is in Slave Mode
[ 327][E][Wire.cpp:331] endTransmission(): Bus is in Slave Mode
[ 333][E][Wire.cpp:260] getClock(): Bus is in Slave Mode

[ifrew]

Ok. I'll look for that. I just cleared everything and reloaded your latest m5stack-sdupdater from github v 1.2.0 using chimera core 1.4.5 and lgfx v 0.4.17. Rebuilt the example. Sure enough, it works on a standalone m5stack gray module. I had a spare new M5Stack Lora 868 module . As soon as I add that it fails with the errors we have seen. So at least its easily to repro now. Be interesting if you had any m5stack SPI devices around to add to the module and see if it fails. If you let me know how to deselect auto connect and just connect directly to the M5Stack Board I can try that. I saw some macro directives, but for some reason commenting out autoconnect and replacing with the m5stack board in the LGFX library led to compiler issues in Visual Studio 2019 running Vmicro.

[EDIT} Interestingly I thought I had just found the problem and got super excited. My 'fix' makes it much more stable than before but after a lot of continuous resets, like 15, the problem reappears and you need to erase and reflash to get rid of the problem or it gets worse. I added pinMode(5,OUTPUT); in your example code just before M5.Begin(); Pin 5 is my SPI CS pin. It works like a treat for a while before falling over. So I thought the LGFX library was not setting the pinmode to be OUTPUT for the CS pin However, looking a the code it does indeed set it within _pin_level() routine. However, adding pinmode(5, OUTPUT) definitely makes a difference. Maybe there is some lower level bug setting pinMode within LGFX. Food for thought.

[EDIT] At boot time with ESP32 the pins are not configured so it's important to specify for SPI CS pins on a shared bus that they are OUTPUT to avoid floating values until the bus starts up

[ifrew]

Ok folks. Finally put to bed this issue I'm sure. As I said, adding the pinMode(5,Output) for my board made a big difference but it would still fail eventually after a number of soft resets. I don't have an oscilloscope only a digital multi meter but I could see the voltages vary between each reset going up to around 3v +/- 0.2v and then turn off with capacitor discharge down to millivolts. However sometime it wouldn't quite reach 3v and then it started doing the wierd things. Normally you don't need pullup resistors on outputs since the bus is driving but it seems with the CS control line setting it High doesn't always set it high. So I added a strong pullup resistor of 470 Ohms between pin 5 and the 3.3V line on the M5stack bus with the Lora module attached and supplied voltage with 5v via USB C cable. I reset the device 50 times with no issues always reading the SD card! I pulled out the resistor and got to 7 resets before it failed. I repeated this test twice and same results both times. So it seems the internal pullup resistors of the M5 are quite weak.

In summary, you need to use pinMode(pin number, OUTPUT) before M5.Begin() when using SDUpdater with multiple SPI devices on the M5Stack, and for additional security, also have a strong pull-up 470 Ohm resistor between the CS Pin of your SPI devices and the 3.3v line.

Thanks folks...normal service returns! I'll let you close this one out @tobozo !

Cheers Iain

Further information on SPI pull-up resistor on shared bus can be found here https://hackaday.com/2014/11/25/better-spi-bus-design/#comments