-
So maybe you don't actually want to use SPIFLASH_SLEEP_CMD, but instead want to change that ifdef to enable it for your watch (not just the Bangle.js 2)
looks like that is some workaround for Q3 to do it 3 times but it is still there for other devices too
https://github.com/espruino/Espruino/blob/e0ed6eb68b672ddc1ce092dfc7096c4697b4382b/targets/nrf5x/jshardware.c#L804@yngv126399 I still don't get why they share I2C and SPI pins for this watch as they had may other pins available. would make sense if the accelerometer would be configured as SPI too but it is not the case here. so it may make sense to keep the shared data pin floating when both flash and accelerometer communication is not in progress(?) then reconfiguring it before starting i2c or spi communication. But still, is the clock pin shared for clock for both spi and i2c? Then I don't know how the accelerometer is prevented from receiving spi communication and possibly misinterpreting that and messing data transfer for SPI on data pin - causing random errors (that you described in first post?). You can pull SPI CS high to let SPI flash not mess up I2C but what to do for the other way?
That's an odd one - I just checked and
SPIFLASH_SLEEP_CMD
really should ensure thatQSPI_STD_CMD_SLEEP
is sent to the flash chip.Do you know what the flash chip in the watch actually is? Maybe it doesn't honour that command.
Or... maybe when it goes to sleep it pulls the MISO pin low, and that then is fighting against the accelerometer and wasting power?
I was just looking through the code, and in
jshardware.c
andjshResetPeripherals
I can see:So maybe you don't actually want to use SPIFLASH_SLEEP_CMD, but instead want to change that ifdef to enable it for your watch (not just the Bangle.js 2)?