danak6jq / Seeed-LoRa-E5

LoRaWAN end node built from scratch using CubeMX for WLE5x in the LoRa-E5
Other
46 stars 10 forks source link

Use the code on custom boards #15

Closed kargarisaac closed 1 year ago

kargarisaac commented 2 years ago

Hello,

I have one custom board and want to connect it to Helium. I've done this using esp32 + grove lora-e5 module. I also got the lora-e5 mini board but I cannot program it. I changed RDP to AA using cubeProgrammer but I'm not sure if this is the AT firmware cleaning or I have to do sth else. I didn't understand the section on seeed blog for lora-e5 mini (you also linked that in your readme).

My final goal is to program my own board and connect it to TTN or Helium. What should I do in order to use your code on my board? Should I just disable pinout configs for push buttons and LEDs? Which ones I have to keep and not change? I try to start a project with stm32wl MCUs but I see the LoRaWAN option in cubeMX is disabled. I'm totally confused here and found your repo as a from scratch gude which I appreciate. If you have any thought that can help me solve this problem, I would be appreciated :)

Thank you, Isaac

danak6jq commented 2 years ago

@kargarisaac so you have an ST-Link (or compatible SWDIO programmer)?

Factory AT Firmware is programmed with RDP(Read Protection) Level 1, developers need to remove RDP first with STM32Cube Programmer. Note that regression RDP to level 0 will cause a flash memory mass to erase and the Factory AT Firmware can't be restored again.

So you've changed RDP - did you change it to level 0? (I haven't done this recently and don't immediately recall the CubeProgrammer details there). If so, that erases the MCU and you should be able to program it. It's been a few months or maybe longer since I last did this (maybe a year!)

To re-use this example project, yes, basically remove the configuration for the buttons and LEDs from the IOC (CubeMX configuration) and the associated code in LoRaWAN/App/lora_app.c (and possibly elsewhere, though I don't recall anything). My most recent merge removes the LED control code by commenting it out, example: `#if 0 // XXX: HAL_GPIO_WritePin(LED3_GPIO_Port, LED3_Pin, GPIO_PIN_RESET); / LED_RED /

endif`

There's also the ISR for button 1: void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { switch (GPIO_Pin) { case BUT1_Pin: // XXX: always initialized if (EventType == TX_ON_EVENT || 1) { UTIL_SEQ_SetTask((1 << CFG_SEQ_Task_LoRaSendOnTxTimerOrButtonEvent), CFG_SEQ_Prio_0); } break; default: break; } }

and this configuration in the IOC

image

I believe you can just reset the configuration of that pin and remove the ISR. In fact, you may just reset all the I/O pins you are not using in the IOC, regenerate the project, and see what breaks when compiled (references to deleted I/O).

Be careful about changes to lora_app.c - anything you add/change must be enclosed in USER CODE comments or it will be deleted on CubeMX regeneration.

Also, note that my latest merge uses the internal ST-provided EUI, so you no longer need the Seeed-provided EUI, though you can continue to use it.

I hope this helps!

kargarisaac commented 2 years ago

Thank you for the answer. One more question. What about BSP. I don't understand it. I see in some slides, like the following, that I need to change something like control pins. But I don't understand what they are and what is the use case.

image source

Do you know what should I do for a custom board?

kargarisaac commented 2 years ago

I also try to use the seed dev board and changed LoRa configs as you mentioned in the steps in the readme and built the project. But I cannot program the board.

In cubeIde:

Copyright (c) 2022, STMicroelectronics. All rights reserved.

Starting server with the following options:
        Persistent Mode            : Disabled
        Logging Level              : 1
        Listen Port Number         : 61234
        Status Refresh Delay       : 15s
        Verbose Mode               : Disabled
        SWD Debug                  : Enabled

Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
Failed to read registers from target
Shutting down...
Exit.

in cubeProgrammer:

image

I cannot even push a simple blinking code to the board. The RDP level is changed as follows:

image

I also cannot erase the chip:

image

I spent more than two weeks to find the problem but cannot find a solution. If I can make the code work on the dev board, then it would be easier to write a code for my custom board.

Do you have any idea what might be wrong?

danak6jq commented 2 years ago

Thank you for the answer. One more question. What about BSP. I don't understand it. I see in some slides, like the following, that I need to change something like control pins. But I don't understand what they are and what is the use case.

Do you know what should I do for a custom board?

Generally speaking, the BSP must match the configuration of the custom board. Several GPIOs are dedicated to controlling parts of the radio external to the MCU (the RF switch), also the BSP needs to be configured to reflect other design choices (such as TCXO vs crystal oscillator, or selection of high-power/low-power amplifier outputs and any associated switching).

danak6jq commented 2 years ago

I'm not sure what to do with CubeProgrammer there - have you tried asking on the ST forums?

kargarisaac commented 2 years ago

Thanks for the answers. Yeah I didn't get any clear answer yet. Thought maybe someone worked with the same board can help. I ordered a new nucleo-wl board.