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

@lupyuen
Cc @mkljczk kopnal bys to do opensourceowych geekowych linkow etc?

@lupyuen
Interested in riscv. Please tell me more. Are You Chinese? Based in cm or us?

I need nickname for ya. Im bad bad with little worms for characters. No offence meant. Honestly.

Ill try to promote you around polish opensource geeky part of fedi if you want.

@PawelK Hi call me Lup (rhymes with "Up"), I'm just a geek in Singapore. Here's the story of my life 😉 ...

https://lupyuen.github.io/

I'm tied up with #RISCV #BL602 #LoRa projects right now ... Sorry I won't be able to help you much

@lupyuen
No worries. Thanks for intro im polish retired young. Based c/cpp. 15 years of exp. Mostly embeds. Some 4g and 5g infrastructure devel experience. Selftaught. IT is my life. Nerd. Pro opensource.

Riscv is the postarm. We need it badly.

@lupyuen
Also what could interest You Sir is llvm+clang seem to support riscv. They seem nicer fuller and more maintainable than gcc if that was of any help. Methinks #clangisthenewgcc

@lupyuen
Hmm lora nice nice.

@lupyuen
Are those two platforms using two different operating systems? Generally depends whether irq handler lives in same adress space as setup code. General guideline for portable code should be using either static data accessible from irq code or dynamically allocated data passable between two adress spaces.

@lupyuen
In case both oses are same or with same model of memory segments divide/sharing, seems like a bug to me.

@PawelK Yeah the code looks a bit suspicious ... Generally I would never save a pointer to a stack object. But this code has been in Apache Mynewt OS for a long time 🤔

@lupyuen
Ah ok clear now. Generally struct copy. Dont pass pointers. Unsafe.

@lupyuen
This code has assumption os shares adress space between irq segment and irq setup code.

Sorry for side comment. Deleted. Mistake.

@lupyuen
What puzzles me is fact mynewt is os in itself. Hmm weird.

@lupyuen
My reasoning is mynewt on both platforms should have constraints on segment duvide/sharing independent of platform. Thats puzzling.

@lupyuen
Lovely. Wish You much success. Interesting project and great platform. Whats the planned use for these little animals?

@PawelK Thanks :-) I'm planning to use this for IoT Education ... Teaching folks how to create a RISC-V LoRa Sensor that's battery powered...

https://lupyuen.github.io/articles/lora

https://lupyuen.github.io/articles/wisblock

@lupyuen
Nice nice. We coud use this in poland such a course. 5g is planned/starting rollout.

@lupyuen
Nice project. A hobby or commercial?

@lupyuen
If platforms are ready i might try to promote your platform here. It sounds interesting.

@lupyuen
Need to learn more on lora though for final decision.

Also in your example each process has separate stack while globals are in shared adress space. Interesting os. Feels similar to what i was doing for ericsson.

@lupyuen
Ahhh now i see. Lemme browse through their source. Old code is borked. Youre assigning to struct type a pointer type instead of RadioEvents = *events.

How come compiler let it compile...

@PawelK I changed my version to use struct instead of pointer to struct:

https://github.com/lupyuen/bl_iot_sdk/commit/5ca7946da1f795fd53aa7937ae87f3fbea2bce2a#diff-96c07c83d9cb748e9326fc2de5671debed63687a1fc984ff73cada89001a96fa

@lupyuen
If we got code:
Struct RadioEvents_t a.
Fun(struct RadioEvents_t* b)
{
a=b;
}

Compiler should give error.

@PawelK The original code is this:

static RadioEvents_t *RadioEvents;

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

@lupyuen
Ahh ah. Ok its porting between oses and separate adress spacrs problem it seems. Another concern may be if struct shoukdnt be volatile but i dont know enough sbout code to tell.

@lupyuen
You know when volatie is useful for sure, right?

@lupyuen
Ahhhh ok.

Yea segment sharing/divide between irq and irq setup.

@lupyuen
Yes your compiler is broken. How come can you struct = pointer without dereference? Hehe.

@lupyuen
Cc @syuilo keep link to this guy. It will matter later. Embeds will with emphasis on arm and later riscv.