#BL602 now displays the #LoRa Packet received from #WisBlock yay!

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/demo.c

Mystery #BL602 GPIO Function ... What does it do? Will it fix our problem with triggering multiple GPIO Interrupts? 🤔

https://github.com/bouffalolab/bl_iot_sdk/blob/master/components/bl602/bl602_std/bl602_std/StdDriver/Src/bl602_glb.c#L2244-L2264

#BL602 Reference Manual mentions "GPIO_INT_CLR" but the address is undefined in the doc ... Methinks a chunk of addresses are missing from the doc 🤔

https://github.com/bouffalolab/bl_docs/tree/main/BL602_RM/en

Searching GitHub for "GPIO_INT_CLR" shows ultraembedded RISC-V SoC ... Coincidence? 🤔

https://github.com/search?l=Markdown&q=GPIO_INT_CLR&type=Code

Ah my folly ways ... Multiple #BL602 GPIO Interrupts can't be registered like this ... Lemme fix this 🪠

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/sx1276-board.c#L336-L396

#BL602 supports only one Interrupt Handler for all GPIO Pins ... Let's iterate thru the #LoRa SX1276 Interrupts and handle them

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/sx1276-board.c#L404-L461

#BL602 now detects Multiple GPIO Interrupts ... Triggered by #LoRa SX1276 yay!

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/sx1276-board.c#L404-L461

Let's handle #BL602 GPIO Interrupts the smarter way ... By iterating thru the Interrupt Events created with the NimBLE Porting Layer

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/sx1276-board.c#L369-L397

Reconnected #PineCone #BL602 @PINE64 ... To #LoRa SX1276 pins DIO0 to DIO3 ... For testing our GPIO interrupt handler

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/sx1276.h

Enabled #BL602 GPIO Interrupt Handler for #LoRa SX1276 ... And BL602 hits a #RISCV Exception ... At an invalid Program Address 🤔

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/demo.c

Let's disable #LoRa Channel Activity Detection for now ... #BL602 receives first LoRa Packet ... But not the second packet 🤔

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/demo.c

Never clear the #BL602 GPIO Interrupt Status! 🚧 ... This suppresses subsequent GPIO Interrupts 😲 ... We can now receive multiple #LoRa Packets yay!

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/sx1276-board.c#L402-L433

Can #BL602 show the Stack Trace for this #RISCV Exception? ... Let's find out 🤔

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/demo.c

#BL602 Stack Trace Hieroglyphics ... Can we use this to dump the Stack Trace for our #RISCV Exception? 🤔

https://github.com/bouffalolab/bl_iot_sdk/blob/master/components/bl602/freertos_riscv_ram/panic/panic_c.c#L6-L7

Here's the #BL602 Exception Handler ... Seems capable of showing the #RISCV Stack Trace 🤔

https://github.com/bouffalolab/bl_iot_sdk/blob/master/components/hal_drv/bl602_hal/bl_irq.c#L316-L341

#BL602 shows Stack Trace when CONFIG_ENABLE_FP=1 ... But the addresses don't make sense ... They belong to the code that's dumping the Stack Trace 🤔

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/proj_config.mk#L40-L42

Oops #BL602 needs us to "make clean ; make" to fix up the Stack Frame Pointers ... Now BL602 Stack Trace points to the "ebreak" instruction ... Which belongs to the #RISCV Exception Handler 🙄

https://github.com/lupyuen/bl_iot_sdk/releases/tag/v7.0.1

Deciphering the #BL602 Stack Trace Hieroglyphics ... There must be a way to get the Stack Frame before our #RISCV Exception 🤔

https://github.com/bouffalolab/bl_iot_sdk/blob/master/components/bl602/freertos_riscv_ram/panic/panic_c.c#L6-L7

#BL602 Stack Trace always shows the Current Stack ... Let's show the stack before hitting the #RISCV Exception

https://github.com/bouffalolab/bl_iot_sdk/blob/master/components/bl602/freertos_riscv_ram/panic/panic_c.c#L75-L98

Let's dump the #BL602 Stack with this function ... And figure out why our Exception Stack Trace doesn't look right

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/demo.c#L469-L488

Here are the #BL602 Stacks for the Foreground RTOS Task, Background Task and Exception Handler ... Let's see what's wrong with the Exception Stack

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/demo.c#L469-L488

Complete #BL602 Stack Data for the Exception is here

https://gist.github.com/lupyuen/5ddbcdd1054c775521291c3d114f6cee

Below the #BL602 Exception Handler Stack ... Is another Stack! ... Does this Stack contain the Stack Trace that we need? 🤔

https://gist.github.com/lupyuen/5ddbcdd1054c775521291c3d114f6cee

Quiz: What's wrong with this C code? 🤔 ... I'm soooo upset I missed this simple bug 🙄

https://github.com/apache/mynewt-core/blob/master/apps/loraping/src/main.c#L215-L233

Answer: "radio_events" contains Undefined Fields ... Because it was allocated on the Stack! Lesson Learnt: ALWAYS Init Stack Variables! 🙏

https://github.com/apache/mynewt-core/blob/master/apps/loraping/src/main.c#L215-L233

Here's how we fixed the #BL602 Exception for #LoRa Channel Activity Detection ... Always init Stack Variables! 🙏

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/demo.c#L127-L143

Back to our #BL602 Stack Trace ... Yep the Correct Stack Trace is indeed lurking behind our (unhelpful) Exception Stack Trace ... How shall we show the Correct Stack Trace beyond the Emptiness? 🤔

https://gist.github.com/lupyuen/5ddbcdd1054c775521291c3d114f6cee

#PineCone #BL602 @PINE64 receives #LoRa Packets from RAKwireless #WisBlock ... Almost finished! One more thang ...

https://youtu.be/3TSvo0dwwnQ

To conserve battery power, #LoRa Sensors don't always listen for incoming packets ... They listen for a few seconds then go back to sleep. 😴 LoRa Receive Timeout is the last thing we shall implement for #BL602

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/demo.c#L207-L215

Let's do #BL602 #LoRa Receive Timeout with these Callout Functions from the NimBLE Porting Layer

https://lupyuen.github.io/pinetime-rust-mynewt/articles/dfu#nimble-callout-functions

Here are the #BL602 #LoRa Timer Functions that we shall implement with NimBLE Porting Layer

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/sx1276.c#L214-L263

#BL602 receives 4 #LoRa Packets by executing 458 SPI requests ... Great load test for SPI 👍

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/demo.c

#BL602 #LoRa Driver creates hundreds of SPI DMA Requests ... Each request reads / writes only ONE byte! 🙄 ... Note to future self: Combine the SPI DMA Requests

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/sx1276.c#L265-L306

@lupyuen
What hw part is being talked to over said dma? Does order of dma reads matter? Can you cache requests issue dma read burst and send result asynchronously etc or per queue keeping order? We had similar problem in nokia on radiomodules i think. Dont remember exact solution though.

@PawelK I ported the driver from Mynewt OS to BL602.

Since I don't have the time to redesign the driver and do a thorough regression test ... We'll have to live with this inefficiency for now.

@lupyuen
Can you let me peek at source before port and after port? Curious. Not strong in dma but curious of it.

@PawelK Original LoRa SX1276 Driver for Mynewt OS:

https://github.com/apache/mynewt-core/blob/master/hw/drivers/lora/sx1276/src/sx1276.c

Ported to BL602:

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/sx1276.c#L265-L307

The original code calls "hal_spi_tx_val", which is a Mynewt SPI Function that transfers 1 byte over SPI. It's clearly not designed for DMA.

@lupyuen
Ahh dma is sync and regions are continuous. Looks easy peasy. Ill try to play with this code if youll allow. Wish i had a board to play with.