particle-iot-archived / core-common-lib Goto Github PK

Thanks to Jerry of Choosatron for pointing this out. Currently, a debug build leads to a breathing green light and a core hung with these as its last debug messages:

0000000565:<WARN > SPI_DMA_IntHandler (437):CC3000 DmaHandler release write spi bus
0000001496:<WARN > SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
0000001497:<WARN > SpiWrite (334):CC3000 SpiWrite acquire bus
0000001497:<WARN > SPI_DMA_IntHandler (437):CC3000 DmaHandler release write spi bus
00000016n2ler (408):CC3000 DmaHandler release read spi bus
0000001613:<WARN > SpiWrite (334):CC3000 SpiWrite acquire bus
0000001614:<WARN > SPI_DMA_IntHandler (437):CC30ite spi bus
0000001616:<WARN > SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
0000001617:<WARN > SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
0000001618:<ERROR> hci_event_handler (555):type != HCI_TYPE_EVNT is (2) usRxDataPending=0 usRxEventOpcode=513 usReceivedEventOpcode=0
0000001744:<WARN > SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
0000002161:<WARN > SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus

Found while reviewing issue #23 / #24, but appears to have been there for a while. Requires a lot of digging into what the host driver event handler does with a length passed by reference to be output.

../CC3000_Host_Driver/nvmem.c: In function 'nvmem_read':
../CC3000_Host_Driver/nvmem.c:109:2: warning: passing argument 3 of 'SimpleLinkWaitData' from incompatible pointer type [enabled by default]
In file included from ../CC3000_Host_Driver/nvmem.h:38:0,
                 from ../CC3000_Host_Driver/nvmem.c:45:
../CC3000_Host_Driver/cc3000_common.h:260:13: note: expected 'UINT8 *' but argument is of type 'INT32 *'

and

../CC3000_Host_Driver/socket.c: In function 'simple_link_recv':
../CC3000_Host_Driver/socket.c:895:3: warning: passing argument 3 of 'SimpleLinkWaitData' from incompatible pointer type [enabled by default]
In file included from ../CC3000_Host_Driver/hci.h:38:0,
                 from ../CC3000_Host_Driver/socket.c:47:
../CC3000_Host_Driver/cc3000_common.h:260:13: note: expected 'UINT8 *' but argument is of type 'long int *'

I'm extremely new to systems programming, but I had a quick look at the firmware and while you seem to be using the AHB for the CC3000, it doesn't seem to be used for anything else (like the GPIO). Would it make sense to look at using the AHB?

It may not make sense in this case. I also don't know what kind of resource/performance benefits would result.

As far as I know, Spark Core is using STM32+CC3000. They are good. But even to make Spark Core better, it'll need to support more MCU & WIFI modules in the future, so that people will have more choice.

I think a common HAL layer or HAL APIs can be designed, so that the specific MCU & WIFI module drivers/softwares can be separated and modularized.

Actually, I can help on this in my spare time since I'm interested in Spark Core.

Would it be possible to add a recovery / testing step during something like a factory reset that tests the external flash memory to find misbehaving / damaged pages, and then move the OTA backup / storage addresses?

This has been a relatively rare failure case I've seen in the wild (less than 10 units), but we could also potentially recover from it purely with software, and potentially it might help us add an abstraction layer on that memory. It could help with reliability for user firmware as well.

Maybe a crazy idea, given the application / ram space, but maybe down the road?

Merge must be done very carefully because we have modified the host driver. git diff and git blame can be helpful commands here, e.g., git blame -L 880,922 socket.c would show that most of simple_link_recv had not changed since August 2013, but that lines 906-916 changed in February 2014.

See http://processors.wiki.ti.com/index.php/CC3000_Release_Notes