Our #BL602 Build, Flash and Run Firmware script generates the #RISCV Disassembly ... Let's track down the address of the RISC-V Exception

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/run.sh

Oops the Program Counter for our #RISCV Exception is null ... So there must be a missing Callback Function somewhere in our #LoRa #BL602 Firmware 🤔

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

#BL602 #LoRa Exception happened because we passed a pointer to a stack object ... Which gets used by the Interrupt Handler 😲 ... This works OK in the original Mynewt code, but not for BL602

https://gist.github.com/lupyuen/1539f9dd52e9a83d4fbe7724481112bf

For #BL602 we fix this exception by copying the object ... Instead of storing a pointer to the object

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

#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 wow, that is some crappy implementation by the sound of it! Honestly I am surprised, usually the low-level uC people (the ones working with assembly and C) tend to do a way better job than that.