Murata LoRa SOC bootloader

[SARTHAK KELAPURE]

Posted on January 11, 2018 at 07:54

I have a Murata LoRa SOC from which I have made up a custom board and I am flashing code using UART which wasn't successful until help from

https://community.st.com/people/Turvey.Clive.002

‌

Now I am using stm32flash open source software for flashing of code but after successful flashing I still am not even able to blink a LED using the flashed code. While the software did work when flashed to DISCOVERY kit.

I reckon this must be because the ICs aren't shipped with bootloader? Is it? But then how did the flashing work? I am so confused. Please help.

PS: Boot configurations are perfectly alright.

#stm32l0 #b-l072z-lrwan1 Note: this post was migrated and contained many threaded conversations, some content may be missing.

[AvaTar]

Posted on January 11, 2018 at 09:08

Are your custom board and the Discovery using the same MCU type ?

Are the LEDs you try to blink on the same pin(s) ?

Are the clock source (quartz, frequency) the same ?

I reckon this must be because the ICs aren't shipped with bootloader?

If you mean the system bootloader (entered via BOOT0/BOOT1), no.

This bootloader is in ROM, and always present.

I don't know any Discovery kit that uses a second-stage bootloader.

But if your LoRa SoC has such a second stage BL, it most probably conflichts with your test application.

I would try a JTAG/SWD adaptor (like STLink) to flash, and a toolchain.

[Andrew Neil]

Posted on January 11, 2018 at 10:36

SARTHAK KELAPURE wrote:

I have a Murata LoRa SOC

You mean the 'Type ABZ' module:

https://wireless.murata.com/eng/products/rf-modules-1/lpwa/type-abz.html

https://wireless.murata.com/media/catalog/product/cache/3/image/9df78eab33525d08d6e5fb8d27136e95/t/y/typeabz.jpg

Note that this is not a SoC; it is an

STM32L072 microcontroller and a Semtech SX1276 Radio - two separate chips.

Sorry - I can't see the rest of your text due to the forum faults.

[Tesla DeLorean]

Posted on January 11, 2018 at 16:47

In another post you indicate the lack of SWD (SWCLK,SWDIO), hopefully you have at least test points or edge castellations where you can access these signals, otherwise your design is going to be a bit of a bear to debug and bring up.

The BOOT0 high configuration seems to get you into the loader. In normal operation this should be pulled low. You should also be able to read out the code written to confirm the correct delivery.

You will need to simplify your test code so you can see how far beyond Reset_Handler you get. You should perhaps just let the part run of the initial clock rather than change them or enable the PLL.

I might start by adding code into the Reset_Handler to enable a GPIO clock, and a GPIO pin, and then toggle that in a way I can scope to prove the part is alive, and that my code can run. Once you have done that look for code that sticks in spin loops or bombs silently into Error_Handler(), etc.

[Tesla DeLorean]

Posted on January 11, 2018 at 16:50

The user activity tab should provide 'Show More' to expand most things. Attachments seem to be an issue, perhaps the cause of the error. Jive's rapid response team of agile programmers is hard at work....

[Andrew Neil]

Posted on January 11, 2018 at 17:19

It won't expand the OP - just the following 'activity'

:(

 

[Andrew Neil]

Posted on January 11, 2018 at 17:57

can see the whole thing in 'inbox' view.

[SARTHAK KELAPURE]

Posted on January 11, 2018 at 18:07

I was just waiting for your reply and with a new update on my situation I am sure you will be able to help,

I am now able to flash using the STM32Cube Programmer. While flashing I kept the BOOT0 low and flashed using UART to address 0x08008000 and without a restart I get the expected output of blinking LEDs. But on restart/reset of my board the application stops working. While the STM32Cube Programmer shows the hex values of all pages, I tried match all the values(from blink.bin and 0x08008000 onwards) and they were same.

What may be the issue and how do we solve?

[Tesla DeLorean]

Posted on January 11, 2018 at 18:18

The processor pulls initial PC and SP from a Vector Table that it expects to be at 0x08000000. Not sure how it would get to 0x08008000 without some loader code earlier in FLASH to transfer control there.

[SARTHAK KELAPURE]

Posted on January 11, 2018 at 18:21

Well correct, I tried 0x08000000 also but the reset thing still persists.