Since I uploaded my stm32cubef1 firmware version up to 1.6.0, I can't debug anymore my board. I'm using SWSTM32 and ST-LINK/V2.
Once I press the "play" like button, when I try to stop it a Windows opens and it says:
"No source available for "dt_TPS()at 0x20000004"
where dt_TPS is one of my variables.
In the window at the bottom of the page I read this:
Open On-Chip Debugger 0.10.0-dev-00302-gc211ca5-dirty (2017-07-03-10:41)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
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
srst_only separate srst_nogate srst_open_drain connect_assert_srst
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : clock speed 1000 kHz
Info : STLINK v2 JTAG v28 API v2 SWIM v6 VID 0x0483 PID 0x3748
Info : vid/pid are not identical: 0x0483/0x374B 0x0483/0x3748
Info : using stlink api v2
Info : Target voltage: 3.239921
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : STM32F105R8Tx.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
STM32F105R8Tx.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x200001e0 msp: 0x20005000
Info : device id = 0x10016418
Info : flash size = 64kbytes
STM32F105R8Tx.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x200001e0 msp: 0x20005000
STM32F105R8Tx.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x200001e0 msp: 0x20005000
Info : Padding image section 0 with 4 bytes
STM32F105R8Tx.cpu: target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0x20005000
STM32F105R8Tx.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x200001e0 msp: 0x20005000
Error: address + size wrapped(0xffffffff, 0x00000004)
Error: address + size wrapped(0xffffffff, 0x00000002)
Error: address + size wrapped(0xffffffff, 0x00000004)
Error: address + size wrapped(0xffffffff, 0x00000002)
Other infos: my current toolchain is: AC6 STM32 MCU GCC, current builder: Gnu Make Builder and the micro I used is STM32F105R8T6
Does anyone know what's going on?
You appear to be executing code from SRAM rather then flash. That is unusual, and possibly not intentional.
The processor will execute from SRAM on reset when the BOOT0 and BOOT1 pins are both high. Normally you load and execute code from flash (BOOT0 low, BOOT1 don't care) - your board may have jumpers for boot mode selection.
Related
Linux kernel : 5.4.24
We are using bluez with a 5.0 feature enabled controller. When doing hciconfig hci0 reset we can see that in LE Set Extended Advertising Parameters even when properties is set as ADV_NONCONN_IND legacy as below:
< HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036) plen 25 #83 [hci0] 9.977909
Handle: 0x00
Properties: 0x0010
Use legacy advertising PDUs: ADV_NONCONN_IND
We can still see bluez sending Ext Scan Rsp Data as below:
< HCI Command: LE Set Extended Scan Response Data (0x08|0x0038) plen 35 #87 [hci0] 9.984415
Handle: 0x00
Operation: Complete scan response data (0x03)
Fragment preference: Minimize fragmentation (0x01)
Data length: 0x0c
Name (complete): pvqseqevk
And since spec says :
If the advertising set is non-scannable and the Host uses this command other
than to discard existing data, the Controller shall return the error code Invalid
HCI Command Parameters (0x12).
The controller is returning this error:
> HCI Event: Command Complete (0x0e) plen 4 #88 [hci0] 9.989066
LE Set Extended Scan Response Data (0x08|0x0038) ncmd 1
Status: Invalid HCI Command Parameters (0x12)
Also, after this command the next commands are passing as seen in hcidump/btmon, but the kernel throws error because this command fails.
My question is , what is the expected behavior?
If this behavior is correct, should we just ignore the error?
If the behavior is wrong, is there any fix already for this?
I cant see the input device in alsamixer on the usb board, but it is listed as I do arecord -L (also why is it listing the 2nd sound card by default ?)
arecord -l
**** List of CAPTURE Hardware Devices ****
card 1: CODEC [USB Audio CODEC], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
I can see many informations but I cant figure from man, how to change the level of the line input in command line nor in the gui
amixer info
Card default 'CODEC'/'Burr-Brown from TI USB Audio CODEC at usb-3f980000.usb-1.3, full speed'
Mixer name : 'USB Mixer'
Components : 'USB08bb:2902'
Controls : 4
Simple ctrls : 1
amixer contents
numid=3,iface=MIXER,name='PCM Playback Switch'
; type=BOOLEAN,access=rw------,values=1
: values=on
numid=4,iface=MIXER,name='PCM Playback Volume'
; type=INTEGER,access=rw---R--,values=2,min=0,max=128,step=0
: values=128,128
| dBminmax-min=-128.00dB,max=0.00dB
numid=2,iface=PCM,name='Capture Channel Map'
; type=INTEGER,access=r----R--,values=2,min=0,max=36,step=0
: values=0,0
| container
| chmap-fixed=FL,FR
| chmap-fixed=MONO
numid=1,iface=PCM,name='Playback Channel Map'
; type=INTEGER,access=r----R--,values=2,min=0,max=36,step=0
: values=0,0
| container
| chmap-fixed=FL,FR
| chmap-fixed=MONO
I am actualy not sure about how to achieve this since many people say thousands of different thing
here I try to set the volume in a clumsy way, and it does not work :
amixer -c 1 sset numid=2 0
amixer: Unable to find simple control 'numid=2',0
amixer -c 1 cset numid=2 0
amixer: Control hw:1 element write error: Operation not permitted
sudo amixer -c 1 cset numid=2 0
amixer: Control hw:1 element write error: Operation not permitted
amixer does not list any record device although I can clearly record audio with audacity or puredata
amixer -c 1
Simple mixer control 'PCM',0
Capabilities: pvolume pswitch pswitch-joined
Playback channels: Front Left - Front Right
Limits: Playback 0 - 128
Mono:
Front Left: Playback 128 [100%] [0.00dB] [on]
Front Right: Playback 128 [100%] [0.00dB] [on]
amixer -c 0
Simple mixer control 'PCM',0
Capabilities: pvolume pvolume-joined pswitch pswitch-joined
Playback channels: Mono
Limits: Playback -10239 - 400
Mono: Playback 0 [96%] [0.00dB] [on]
please help me out, this makes no sens at all to me
thanks guys
amixer and alsamixer shows those mixer controls that the hardware actually has.
As figure 31 in the PCM2902 datasheet shows, this device indeed has no mechanism to change the capture volume:
It might be possible to add a softvol plugin, but it would be easier to just use PulseAudio.
I am using this port of FreeRTOS and I am loading it onto the Cortex-M3 within an OMAP4430. This works fine using the remote proc framework and I am able to use RPMsg to communicate with it.
Sometimes, however, rproc fails to load the elf and gives the following error:
rproc remoteproc1: bad phdr da 0x0 mem 0x10310
rproc remoteproc1: Failed to load program segments: -22
rproc remoteproc1: rproc_boot() failed -22
This seems to happen when the size of the elf file gets too large: this happens when the size is 377331 bytes but does not happen when I simply remove a bunch of print statements and bring the size down to 342563 bytes.
I have tracked the error message down to this piece of code: http://lxr.free-electrons.com/source/drivers/remoteproc/remoteproc_elf_loader.c?v=3.9#L188. It seems that rproc_da_to_va is unable to find a segment in memory large enough to fit the ELF.
How can I make sure that there is enough memory for the size of my ELF? Can I tell the kernel that I specifically want a certain region preallocated for this kind of thing? Is there some way to ensure that this part of my ELF remains small?
Thanks!
Make sure that the FreeRTOS configuration constants configTEXT_SIZE and configDATA_SIZE agree with the amounts demanded by your linker script. For example, if your linker script contains
MEMORY
{
TEXT (rwx) : ORIGIN = 0x00000000, LENGTH = 1M
DATA (rwx) : ORIGIN = 0x80000000, LENGTH = 1M
}
then you should set configTEXT_SIZE and configDATA_SIZE to 0x100000.
to be able to run my eSata Sheevaplug with Debian Wheezy I had to upgrade U-Boot to the DENX version.
As step-by-step guide I used this read from Martin Michlmayr. I did the upgrade using screen and a USB stick at the plug.
The upgrade went good and after resetting I got the plug started with the new version.
Marvell>> version
U-Boot 2013.10 (Oct 21 2013 - 21:06:56)
Marvell-Sheevaplug - eSATA - SD/MMC
gcc (Debian 4.8.1-9) 4.8.1
GNU ld (GNU Binutils for Debian) 2.23.52.20130727
Marvell>>
In the guide is written to set machid environment variable and MAC address.
But unfortunatly saveenv fails due to bad blocks in the NAND. I tried different versions of U-Boot also the one provided by NewIT. All behave the same way.
Marvell>> setenv machid a76
Marvell>> saveenv
Saving Environment to NAND...
Erasing NAND...
Skipping bad block at 0x00060000
Writing to NAND... FAILED!
There are some blocks marked as bad, which might be normal - by NewIT.
Marvell>> nand info
Device 0: nand0, sector size 128 KiB
Page size 2048 b
OOB size 64 b
Erase size 131072 b
Marvell>> nand bad
Device 0 bad blocks:
00060000
00120000
00360000
039c0000
0c300000
10dc0000
1ac40000
1f1c0000
Has someone a clue what the problem is and what I need to change to be able saving environment variables in u-boot?
Thanks,
schibbl
Due to configuration of environment variable storage at NAND, the sector size of 128k and a bad block mapping the environment variable storage adress it is not possible to write env to NAND.
Marvell>> nand bad
Device 0 bad blocks:
00060000
...
include/configs/sheevaplug.h which points perfectly to the bad block.
/*
* max 4k env size is enough, but in case of nand
* it has to be rounded to sector size
*/
#define CONFIG_ENV_SIZE 0x20000 /* 128k */
#define CONFIG_ENV_ADDR 0x60000
#define CONFIG_ENV_OFFSET 0x60000 /* env starts here */
Because of unused sector 0x80000 to 0x9FFFF I moved env storage there.
/*
* max 4k env size is enough, but in case of nand
* it has to be rounded to sector size
*/
#define CONFIG_ENV_SIZE 0x20000 /* 128k */
#define CONFIG_ENV_ADDR 0x80000
#define CONFIG_ENV_OFFSET 0x80000 /* env starts here due to bad block */
Beware! We have to ensure our compiled u-boot.kwb is less then 384k. Otherwise we will write u-boot to bad block marked memory and will brick the device.
Best way to recompile with custom env address, is to use Michlmayrs sources, which includes patches for mmc and e-sata support.
I am working on an Embedded ARM9 development board. In that i want rearrange my nand partitions. Can anybody tell me how to do that ?
In my u-boot shell if i give the command mtdparts which gives following information .
Boardcon> mtdparts
device nand0 <nandflash0>, # parts = 7
#: name size offset mask_flags
0: bios 0x00040000 0x00000000 0
1: params 0x00020000 0x00040000 0
2: toc 0x00020000 0x00060000 0
3: eboot 0x00080000 0x00080000 0
4: logo 0x00100000 0x00100000 0
5: kernel 0x00200000 0x00200000 0
6: root 0x03c00000 0x00400000 0
active partition: nand0,0 - (bios) 0x00040000 # 0x00000000
defaults:
mtdids : nand0=nandflash0
mtdparts: mtdparts=nandflash0:256k#0(bios),128k(params),128k(toc),512k(eboot),1024k(logo),2m(kernel),-(root)
Kernel boot message shows the following :
Creating 3 MTD partitions on "NAND 64MiB 3,3V 8-bit":
0x000000000000-0x000000040000 : "Boardcon_Board_uboot"
0x000000200000-0x000000400000 : "Boardcon_Board_kernel"
0x000000400000-0x000003ff8000 : "Boardcon_Board_yaffs2"
Anybody can please explain me what is the relation between both these messages . And which one either kernel or u-boot is responsible for creating partions on nand flash?. As for as i know kernel is not creating partitions on each boot but why the message "Creating 3 MTD partitions"?
For flash devices, either NAND or NOR, there is no partition table on the device itself. That is, you can't read the device in a flash reader and find some table that indicates how many partitions are on the device and where each partition begins and ends. There is only an undifferentiated sequence of blocks. This is a fundamental difference between MTD flash devices and devices such as disks or FTL devices such as MMC.
The partitioning of the flash device is therefore in the eyes of the beholder, that is, either U-Boot or the kernel, and the partitions are "created" when beholder runs. That's why you see the message Creating 3 MTD partitions. It reflects the fact that the flash partitions really only exist in the MTD system of the running kernel, not on the flash device itself.
This leads to a situation in which U-Boot and the kernel can have different definitions of the flash partitions, which is apparently what has happened in the case of the OP.
In U-Boot, you define the flash partitions in the mtdparts environment variable. In the Linux kernel, the flash partitions are defined in the following places:
In older kernels (e.g. 2.6.35 for i.MX28) the flash partitioning could be hard-coded in gpmi-nfc-mil.c or other driver source code. (what a bummer!).
In the newer mainline kernels with device tree support, you can define the MTD paritions in the device tree
In the newer kernels there is usually support for kernel command line partition definition using a command line like root=/dev/mmcblk0p2 rootwait console=ttyS2,115200 mtdparts=nand:6656k(all),1m(squash),-(jffs2)
The type of partitioning support that you have in the kernel therefore depends on the type of flash you are using, whether it's driver supports kernel command line parsing and whether your kernel has device tree support.
In any event, there is an inherent risk of conflict between the U-Boot and kernel partitioning of the flash. Therefore, my recommendation is to define the flash partitions in the U-Boot mtdparts variable and to pass this to the kernel in the U-Boot kernel command line, assuming that your kernel support this option.
you can set the mtdparts environment variable to do so in uboot, and the kernel only use this if you pass this in kernel boot commandline, or else it'll default to the nand partition structure in the kernel source code for your platform, which in this case the 3 MTD partition default.