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?
Related
I want to do mass erase on my msp430f2619 using bsl. I use software jump in my code to invoke bsl. I send 0x80, get 0x90 from BSL(ack). Then i send mass erase command and get 0x90 again. Then i power off my device, then i power on the device, then i send 0x80 and get 0x90, that means there was no mass erase operation.
Read command is not working too. I send password (0xFF 32 times), after that send rx command, then i get few coorect bytes, and then infinite raw of 0xff.
I think i miised something before jump to bsl, please give an example code, or step by step instruction on how to make software jump to bsl and make it work correctly.
If you are sending 0x80 only, then get back 0x90, this confirms you have entered into the BSL since this completes the required synchronization sequence (see section 2.1 of this document). You should not require the "RX password" command since the "Mass erase" command is not protected.
The next sequence after the synchronization is to send the desired command, which should be the "Mass erase". There is a format to each of the BSL commands called the data frame. You want to send the following data frame: eight mandatory bytes (note two dummy bytes), and two checksum bytes. Note the "Mass erase" command does not contain data bytes, but you need to calculate the checksum bytes. Here are the bytes to be sent to perform the mass erase:
80 18 04 04 dd dd 06 A5 CL CH
Where: dd = dummy bytes (any value accepted), CL = Checksum low, CH = Checksum high
After sending this data frame then you should receive the ACK (0x90) byte. Then power off the device.
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.
When sending the FormatPICC command to a MIFARE DESFire EV1 card, I observe the following behavior:
PCD ---> PICC
--------------
0xFC --->
<--- 0x00 or 0x00 + MAC or ERROR CODE
If authenticated with the command 0x0A (legacy (3)DES authentication), the response to the FormatPICC command is only one byte (0x00).
If authenticated with the command 0xAA (AES authentication), the response to the FormatPICC command is the status byte (0x00) plus the MAC.
When I send another command (e.g. GetVersion (0x60)), the response does not contain the MAC regardless of which authentication was used (0x0A or 0xAA).
Why is that difference? Should I still calculate the MAC for such commands (to update crypto state)? Is there some document that explains that?
Your observation seems to be wrong. Once authenticated using either AuthenticateISO (0x1A) with TDES or AuthenticateAES (0xAA), MIFARE DESFire EV1 will return a MAC in response to all commands (except, of course, the authentication commands and SelectApplication, which both reset authentication).
Consequently, a MAC should be returned in response to the GetVersion command. However, note that the GetVersion command is split across 3 frames. The MAC is only appended to the last frame (the one with the status code 0x00):
PCD ---> PICC
--------------
0x60 --->
<--- 0xAF + DATA
0xAF --->
<--- 0xAF + DATA
0xAF --->
<--- 0x00 + DATA + MAC
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.
In DPKD the ETH_RSS_IPV4 data flow is not activated by default for XL710 Intel NIC. So, when you want to distribute packets among lcores you have to select other IPv4 data flows which are supported by XL710, namely ETH_RSS_FRAG_IPV4, ETH_RSS_NONFRAG_IPV4_TCP, ETH_RSS_NONFRAG_IPV4_UDP, ETH_RSS_NONFRAG_IPV4_SCTP, and ETH_RSS_NONFRAG_IPV4_OTHER. However you will face a silly problem when you are dealing with the fragmented IP packets. If you choose to go with ETH_RSS_FRAG_IPV4 and ETH_RSS_NONFRAG_IPV4_TCP options then some fragmented packets of a connection will fall into another queue, because they don't have L4 port numbers. If you exclude ETH_RSS_NONFRAG_IPV4_TCP function then the ETH_RSS_FRAG_IPV4 hash function will not be applied to non-fragmented packets and those packets will go to queue 0. All other combination of hash functions will not work. So, what should we do?
The behavior of XL710 is not compatible with the conventions in DPDK. So, you must directly work with the API offered by i40e driver in order to set up RSS for ETH_RSS_IPV4. As mentioned in the Intel® Ethernet Controller 710 Series Specification Update, page 18 (release Jan 2017):
Functions that require the Hash (RSS) filters on IPv4 packets should
set all IPv4 PCTYPEs in the PFQF_HENA / VFQF_HENA (PCTYPEs 31, 33…36)
Supported packet types (PCTYPE) are mentioned in Intel® Ethernet Controller 710 Series Datasheet pages 597 and 598 (release Jan 2017). You can see that there is no packet type defined for IPv4.
However there is a solution. The clue is to modify the input set for all required flow types (or packet types). Let's try it with testpmd tool which is provided by DPDK in app folder. After compiling DPDK and the app, run the testpmd application:
./app/test-pmd/testpmd -c ff -n 2 -w 0a:00.0 -w 0a:00.1 -- -i --rxq=4 --txq=4
We have two XL710 in our system. With the following commands you can configure XL710 to behave as you want to support IPv4 data flow.
port config all rss all
set_hash_input_set 0 ipv4-tcp src-ipv4 select
set_hash_input_set 0 ipv4-tcp dst-ipv4 add
set_hash_input_set 0 ipv4-udp src-ipv4 select
set_hash_input_set 0 ipv4-udp dst-ipv4 add
set_hash_input_set 1 ipv4-tcp src-ipv4 select
set_hash_input_set 1 ipv4-tcp dst-ipv4 add
set_hash_input_set 1 ipv4-udp src-ipv4 select
set_hash_input_set 1 ipv4-udp dst-ipv4 add
set_hash_global_config 0 default ipv4-frag enable
set_hash_global_config 0 default ipv4-tcp enable
set_hash_global_config 0 default ipv4-udp enable
set_hash_global_config 1 default ipv4-frag enable
set_hash_global_config 1 default ipv4-tcp enable
set_hash_global_config 1 default ipv4-udp enable
It selects the proper input set for TCP and UDP flow types by removing the L4 port section. The set_hash_global_config command enables the symmetric hash if you need it. By modifying the TCP input set, it behaves just like Frag IPv4 flow type and as a result all packets belonging to the same connection go to the same lcore.
Note that the default input set for Frag IPv4 and NonFIPv4, Other is IP4-S and IP4-D. So it doesn't need to be modified. Remember to modify all other IPv4 flows input set and symmetric quality of them.
You can find the API functions of those commands by looking at the source code of the testpmd application.