STM32WB don't enter to the STOP2 MODE - stm32

I took the example of a project Zigbee_OnOff_Client_SED on a module STM32WB5MMGH6TR on custom board.
I have got a supply current of 3 mA instead of 3 μA if the device is connected to hub (H***y) and I have got a supply current of 168 μA instead of 3 μA if the device is connected to Zigbee_OnOff_Server_Coord.
The ST-Link is disconnected.
The symbol STM32WB55xx is redefined to STM32WB5Mxx.
I have tried example PWR_STOP2_RTC but this does not work if I am working on ZigBee stack onboard.
How can I fix sleep mode?
How can I enter the RFD ZigBee stack and RF module in STOP2 mode?

Related

Can't flash CM0+ Core in NUCLEO STM32WL

In a wireless project, I'm using en Nucleo STM32WLJC1 in dual core configuration.
I take DualCore Ping Pong ST code example, that I rework to make my own application.
I didn't touch anything of the CMO+ project, I only work on the applicative layer in CM4.
I've some problems about flashing the CM0+ Core.
The first time I flashed the board it works and now I've most of the times the folowing error when I try to flash the CM0+. It sometimes work one time for no reason.
Pop-up Problem Occurred Windows :
Error in final launch sequence:
Failed to start GDB server Failed to start GDB server Error in
initializing ST-LINK device. Reason: (255) Unknown. Please check power
and cabling to target.
Console informations
STMicroelectronics ST-LINK GDB server. Version 6.0.0 Copyright (c)
2021, 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
Target unknown error 32
Error in initializing ST-LINK device. Reason: Unknown. Please check
power and cabling to target.
It looks like the STlink can't reach the core...
Someone may know what is happening ?
Is there a flashing configuration that has to be done? (to chose which core we want to flash)

bladeRF simulink no device available error

I am connecting the bladeRF x115 to simulink with Matlab 2016a on a windows 10 PC.
I have followed the getting started guide on github:
www.nuand.com/bladeRF-doc/guides/bladeRF_windows_installer
Then I made a simple code as in the picture shown below:
I can simulate it only one time because when I tried to simulate it again I got the following error:
MATLAB System block 'testlinking/MATLAB System' error occurred when invoking 'setupImpl' method of 'bladeRF_Simulink'. The error was thrown from '
'C:\Program Files\bladeRF\matlab\bladeRF.m' at line 116
'C:\Program Files\bladeRF\matlab\bladeRF.m' at line 398
'C:\Program Files\bladeRF\matlab\bladeRF_Simulink.m' at line 364'.
Caused by:
libbladeRF error (-7) in bladeRF_open(): No devices available
Component:Simulink | Category:Block error
The reason for this error is because the led 2 is still blinking(device is in use). But it continues blinking even though I have closed matlab and simulink, and I don't know why?
Have a look at:
https://www.mathworks.com/matlabcentral/fileexchange/74591-communications-toolbox-support-package-for-bladerf-2-0?s_tid=mwa_osa_a
„Communications Toolbox Support Package for BladeRF 2.0“
Download the zip-file and navigate matlab to the directory bladerf.
This worked for me. The simulink block releases the bladerf-board so the Simulinkmodel can be stopped and restarted without problems/errors.
Your device is available with bladeRF cli?
Check:
bladeRF> info
Board: Nuand bladeRF 2.0 (bladerf2)
Serial #: 20f99xxxx
VCTCXO DAC calibration: 0x1de9
FPGA size: 301 KLE
FPGA loaded: yes
Flash size: 128 Mbit
USB bus: 2
USB address: 3
USB speed: SuperSpeed
Backend: libusb
Instance: 0
If is available close the bladerf cli and MATLAB. Open only MATLAB and check again.

Atollic couldn't verify ST device?

trying to program and debug STM32F103 (Bluepill) from Atollic TrueStudio 9.3 I got following message:
STMicroelectronics ST-LINK GDB server. Version 5.1.0 Copyright (c)
2018, 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
Vendor = 0x55
Error in initializing ST-LINK device. Reason: ST-LINK: Could not
verify ST device! Abort connection.
Trying to do the same thing in St-Link utility works without any problems (also erasing and programming):
What could be the problem with this, why does it have problems with verification ?
Tnx for helping in advance!
The problem is that the ID of the STM32F103 on the BluePill and the ID, defined the debugger config files are different. Often the BluePills have counterfeit ICs on them in order to keep the price low, but these do not have the same ID as genuine ICs.
The Instructions/video below are made for STM32CubeIDE however they should also work for TrueSTUDIO.
Video about a workaround: https://youtu.be/bJYp8o7FoYo
Open the Debug Configuration Window
Select ST-LINK(OpenOCD) in the Debug Probe Dropdown
Search stm32f1x.cfg file the C:\ST\STM32CubeIDE_1.2.0\STM32CubeIDE and open it using notepad.
Search for this Line
Now change the ID from 0x1ba01477 to 0x2ba01477 as shown here
Save the file, now debugging should work
this solution also works for clone chips like CH32F103 which is in some cases on BluePill
the other solution is to change a parameter in "stm32f1x.cfg"
open it with a text editor and find this line:
swj_newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
change "$_CPUTAPID" to zero at the end of line it should be like this:
swj_newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0
after that :Open the Debug Configuration Window like picture above and choose "Select ST-LINK(OpenOCD)" in the Debug Probe Dropdown
then click "Show generator options…” and in Mode setup change"Reset Mode”For“Software system reset”.
both of ways works and i've tested them with CubeIDE and CH32f103c8t6.
remember to change jumper on board
jumpers : up = 0 ; down = 1

stm32 factory bootloader possibly overwritten with openocd?

tl;dr: flashed firmware to 0x00000000 instead of 0x08000000, am I lost?
Hello,
my device is based on a STM32F103CBTx which came with a proprietary firmware and had readout protection on.
I connect to it with a ST-Link v2 SWDIO and SWCLK connected to PA13 and PA14 and this command:
sudo openocd -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f1x.cfg
I don't remember how I removed flash protection, but it worked as the original firmware didn't work anymore. Then I created a simple hello world firmware which pulls up and down three gpios and flashed it. The gpios are pulled up and down in 700ms intervals.
After flashing, I can't connect with openocd anymore. I forgot to specify the offset, the manual says the offset defaults to 0 and as it worked, I suppose instead of the boot loader my shitty hello world is pulling up and down some random pins happily… Is this possible? All other threads I found say the boot loader is write protected.
This is the last contact I had:
> halt
halt
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffdc
> flash write_image erase fw.hex
flash write_image erase fw.hex
auto erase enabled
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000003a msp: 0xffffffdc
wrote 4096 bytes from file fw.hex in 0.285697s (14.001 KiB/s)
> reset
reset
jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
Any directions highly appreciated.
Edit:
What I get now, also tried another st-link:
% sudo openocd -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f1x.cfg
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.244356
Error: init mode failed (unable to connect to the target)
in procedure 'init'
in procedure 'ocd_bouncer'
flashed firmware to 0x00000000 instead of 0x08000000, am I lost?
No, it doesn't matter at all, they are the same.
After reset, the MCU loads the word at address 0 in SP, and the next one at address 4 in PC. The BOOT0 and BOOT1 pins control which memory gets mapped to 0x00000000. Usually, BOOT0 is tied low, and flash memory at 0x08000000 gets mirrored at 0x00000000.
instead of the boot loader my shitty hello world is pulling up and down some random pins happily… Is this possible? All other threads I found say the boot loader is write protected.
The factory bootloader is indeed write protected, openocd can't overwrite it.
However, your application could have reconfigured the SWD pins, by writing a wrong value in GPIOA->CRH or AFIO->MAPR, thereby preventing openocd from working. It's the most common cause of this problem.
Fortunately, there is a way to recover.
Connect under Reset
If the reset pin of the controller is held low for a while when openocd is started, the application is prevented from starting, and messing up the GPIO configuration.
Openocd can do this automatically, when
It's told to do so, the line reset_config srst_only srst_nogate is present somewhere in the configuration script.
The MCU reset pin is connected to the debugger hardware, pin 15 on an official ST-Link/V2.
Or you can do it manually, by whatever means your board provides. If you are lucky, it has a reset button, if not, you must find a way to somehow ground the MCU reset pin.
Pull the reset pin low
Start openocd
Wait until the Info : Target voltage line appears. Maybe a second longer.
Release the reset pin.
It requires a bit of trial and error, you'll get better with practice.
Then you can flash your improved application, which carefully avoids reconfiguring the SWD pins.

HFP profile with linux and iphone 5

how can I use hfp on my ubuntu linux with iphone 5s? I have bluetoooth, all bluez packages and ofono installed.
For ofono I need a modem. From what I understood from bluetooth core, protocoll and profile specification, rfcomm and spp of bluetooth can be used to emulate a modem. How does this work with bluez? Do the bluetoothd and ofonod dbus-services already handle incoming connections to hfp oder do I have to write my own listener?
EDIT:
The program is running. I implemented it according to the test-scripts. But I am experiencing audio issues, as I don't have any sound when performing calls. The sound is not muted.
pa log (translated):
Sep 26 13:57:47 ubu2 pulseaudio[2524]: [alsa-sink-Intel ICH]
alsa-sink.c: ALSA woke us up to write new Data on the Device but there
was nothing to write! Sep 26 13:57:47 ubu2 pulseaudio[2524]:
[alsa-sink-Intel ICH] alsa-sink.c: This is most probably an Error of
the ALSA-Driver 'snd_intel8x0'. Please send this error to the
ALSA-Developers. Sep 26 13:57:47 ubu2 pulseaudio[2524]:
[alsa-sink-Intel ICH] alsa-sink.c: We have been woken up by the
POLLOUT-Set, but a following call of snd_pcm_avail() returned the
value 0 or another value smaller than min_avail.
How can I see if ALSA has encountered some errors? I found no log.
When connecting the a2dp-Profile so that my computer are the speakers of the iPhone I also have no sound.
EDIT 2:
To solve this error, this is recommended:
File: /etc/pulse/default.pa
Add tsched=0 to the following line:
load-module module-detect
from post #21 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/374002
But it does not solve my issue. I try force-loading the also modules too.
Having ofono and bluez should be enough.
However, latest version of bluez/ofono and pulseaudio don't support HSP and HFP profiles.
Pulseaudio release notes say that only A2DP is supported with bluez5.x. If you are using
bluez4.x, ofono and pulseaudio 4.x/5.x you might still get this working without a problem.
http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/5.0/
ofono will treat your iPhone 5s as your modem. Once you get the iPhone paired and connected
through bluetoothctl or any alternative GUI, you could run the following ofono tests to see
if ofono picked it up right. Try running ofonod using ofonod -n -d on a terminal to monitor the debug log and probably run pulseaudio in verbose too (pulseaudio -k && pulseaudio -v)
bash$ cd */ofono-1.x/test
This directory contains sample dbus scripts to test the ofono functionalities.
bash$ ./list-modems
[ /hfp/org/bluez/hci0/dev_94_94_26_88_XX_XX ]
Type = hfp
Interfaces = org.ofono.Siri org.ofono.VoiceCallManager org.ofono.CallVolume org.ofono.Handsfree org.ofono.NetworkRegistration
Features = net
Serial = 94:94:26:88:XX:XX
Online = 1
Powered = 1
Lockdown = 0
Emergency = 0
Name = XXXXXX’s iPhone
[ org.ofono.Siri ]
EyesFreeMode = disabled
Enabled = 1
[ org.ofono.VoiceCallManager ]
EmergencyNumbers = 08 000 999 110 112 911 118 119
[ org.ofono.CallVolume ]
Muted = 0
SpeakerVolume = 50
MicrophoneVolume = 50
[ org.ofono.Handsfree ]
VoiceRecognition = 0
InbandRinging = 1
Features = three-way-calling echo-canceling-and-noise-reduction voice-recognition release-all-held release-specified-active-call private-chat create-multiparty
BatteryChargeLevel = 4
SubscriberNumbers = +XXXXXXXXXXXX
EchoCancelingNoiseReduction = 1
[ org.ofono.NetworkRegistration ]
Status = registered
Name = XXX XXXXXX
Mode = auto-only
Strength = 60
If you see output similar to above, enable the modem and try dialling using the following
command and observe ofono debug log if SCO socket is created or rejected. And, of course,
see if the audio is routed to Ubuntu.
bash$ ./enable-modem
bash$ ./dial-number +XXXXXXXXXXXX
...
Similarly, try calling up your iPhone and observe the ofono, pulseaudio logs.
bash$ ./answer-calls
Looks like folks at pulseaudio are trying to get this working with bluez5.x and ofono but
there doesn't seem to be a patch available publicly yet. The bug is being tracked here:
https://bugs.freedesktop.org/show_bug.cgi?id=73325
HFP for Linux is a Bluetooth Hands-Free Profile server.
It allows your Linux system to act as a speakerphone for your mobile phone. It aims to be a compliant Bluetooth HFP 1.5 Hands Free implementation, supporting all required commands and notifications, as well as streaming audio.
http://nohands.sourceforge.net/