I am using flexcan driver on an embedded linux and I have C program controling can messages. In my C program I need to check the state of the can bus e.g. buss-off or error-active. I can use linux command like
ip -details -statistics link show can0 with following result:
2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
link/can promiscuity 0
can state *ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 100
bitrate 250000 sample-point 0.866
tq 266 prop-seg 6 phase-seg1 6 phase-seg2 2 sjw 1
flexcan: tseg1 4..16 tseg2 2..8 sjw 1..4 brp 1..256 brp-inc 1
clock 30000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
31594 0 0 7686 25577 33258
RX: bytes packets errors dropped overrun mcast
5784560 723230 0 1 0 0
TX: bytes packets errors dropped carrier collsns
157896 19742 0 33269 0 0
How can I get that can state ERROR-ACTIVE in my C program? Also I can see in the flex can driver there are some registers that can be used to see the state but I don't know how to include these values in my program also. registers like FLEXCAN_ESR_BOFF_INT contains the values that I need.
You can setup your socket to return CAN errors as messages.
As described in Network Problem Notifications the CAN interface driver
can generate so called Error Message Frames that can optionally be
passed to the user application in the same way as other CAN frames.
The possible errors are divided into different error classes that may
be filtered using the appropriate error mask. To register for every
possible error condition CAN_ERR_MASK can be used as value for the
error mask. The values for the error mask are defined in
linux/can/error.h
can_err_mask_t err_mask = ( CAN_ERR_TX_TIMEOUT | CAN_ERR_BUSOFF );
setsockopt(s, SOL_CAN_RAW, CAN_RAW_ERR_FILTER,
&err_mask, sizeof(err_mask));
See kernel documentation for more information.
Update
Take a look at libsocketcan and the routine can_get_state.
Related
I don't want my code to be repeated several times. Grub4Dos has options for solving this problem, such as functions?
Grub4Dos don't have functions in the usual sense (as in Grub2) but you can use configfile command as functions.
Example:
menu.lst:
set ldpartnew=(hd0,0)/boot/grub4dos/load_partnew.lst
title archlinux-2021.02.01-x86_64
set ISO=(hd0,1)/ISO/archlinux-2021.02.01-x86_64.iso
configfile %ldpartnew%
load_partnew.lst:
partnew (hd0,3) 0 0 0
partnew (hd0,3) 0 0 0
partnew (hd0,3) 0 0 0
ls %ISO% && partnew (hd0,3) 0x00 %ISO%
map %ISO% (hd0,3)
map --hook
root (hd0,3)
chainloader (hd0,3)
Casper:
menu.lst:
set ldcasper=(hd0,0)/boot/grub4dos/load_casper.lst
title ubuntu-20.04.2.0-desktop-amd64
set ISO=(hd0,1)/ISO/ubuntu-20.04.2.0-desktop-amd64.iso
# ISOwohd is path to ISO without (hdX,X)
set ISOwohd=/ISO/ubuntu-20.04.2.0-desktop-amd64.iso
# initrdX is file extension of initrd file
configfile %ldcasper%
load_casper.lst:
map %ISO% (0xff)
echo -e \r\n
map --hook
root (0xff)
kernel (0xff)/casper/vmlinuz%vmlinuzX% file=/cdrom/preseed/ubuntu.seed boot=casper persistent iso-scan/filename=%ISOwohd% splash
initrd (0xff)/casper/initrd%initrdX%
Tested on grub4dos-0.4.6a-2021-01-27.
The problems I encountered in the process of using this method:
A variable name that is too long causes an error.
Since it is impossible to pass parameters to such functions in the usual way, it is necessary to declare additional variables of the type ISO, ISOwohd and initrdX.
I am using ISO8583 Sampler in JMeter for Sending ISO Messages, i had put Necessary Plugins & JAR files like JPOS. However i get "MTI not available" in the Sampler Response
Settings in ISO8583 Connection Configuration
Packager Configuration :- test-generic-validating-packager.xml file from JPOS 2.1.4
Host Name :- 192.168.1.104
Port Number :- 8080
Field wise Data in ISO8583 Sampler
003 380000
011 00000000XXXX
012 20200821${__time(HHmmss,)}
017 20200821
024 200
032 0
034 000000
041 0000000000000MBK
049 INR
102 IBKL 01310200000XXXX
123 MBK
Output of Sampler
Thread Name: Thread Group 1-1
Sample Start: 2020-08-21 17:18:09 IST
Load time: 0
Connect Time: 0
Latency: 0
Size in bytes: 0
Sent bytes:0
Headers size in bytes: 0
Body size in bytes: 0
Sample Count: 1
Error Count: 1
Data type ("text"|"bin"|""): text
Response code:
Response message: org.jpos.iso.ISOException: MTI not available
When i put MTI as 1200 or 0800 in the ISO Sampler, JMeter is unable to send the Request to the Server
Can someone help me out in this??
The same i able to process with Neoload Tool..
As per this documentation aren’t you missing the configuration of field 0 for MTI:
https://github.com/tilln/jmeter-iso8583#iso8583-sampler
I have a problem debugging an stm32f407vet6 board and rust code.
The point of the problem is that GDB ignores breakpoints.
After setting breakpoints and executing the "continue" command in gdb, the program continues to ignore all breakpoints.
The only way to stop the program running is to cause an interrupt using the "ctrl + c" command.
After this command, the board stops its execution on the line currently being executed.
I have tried to set breakpoints on all lines where I can set them, but all the attempts are unsuccessful.
$ openocd
Open On-Chip Debugger 0.10.0 (2020-07-01) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
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 <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 2000 kHz
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : STLINK V2J35S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 6.436364
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f4x.cpu on 3333
Info : Listening on port 3333 for gdb connections
$ arm-none-eabi-gdb -q target\thumbv7em-none-eabihf\debug\test_blink
Reading symbols from target\thumbv7em-none-eabihf\debug\test_blink...
(gdb) target remote :3333
Remote debugging using :3333
0x00004070 in core::ptr::read_volatile (src=0xe000e010) at C:\Users\User\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib/rustlib/src/rust\src/libcore/ptr/mod.rs:1005
1005 pub unsafe fn read_volatile<T>(src: *const T) -> T {
(gdb) load
Loading section .vector_table, size 0x1a8 lma 0x0
Loading section .text, size 0x47bc lma 0x1a8
Loading section .rodata, size 0xbf0 lma 0x4970
Start address 0x47a2, load size 21844
Transfer rate: 100 KB/sec, 5461 bytes/write.
(gdb) b main
Breakpoint 1 at 0x1f2: file src\main.rs, line 15.
(gdb) continue
Continuing.
Program received signal SIGINT, Interrupt.
0x00001530 in cortex_m::peripheral::syst::<impl cortex_m::peripheral::SYST>::has_wrapped (self=0x1000fc6c)
at C:\Users\User\.cargo\registry\src\github.com-1ecc6299db9ec823\cortex-m-0.6.3\src\peripheral/syst.rs:135
135 pub fn has_wrapped(&mut self) -> bool {
(gdb) bt
#0 0x00001530 in cortex_m::peripheral::syst::<impl cortex_m::peripheral::SYST>::has_wrapped (self=0x1000fc6c)
at C:\Users\User\.cargo\registry\src\github.com-1ecc6299db9ec823\cortex-m-0.6.3\src\peripheral/syst.rs:135
#1 0x00003450 in <stm32f4xx_hal::delay::Delay as embedded_hal::blocking::delay::DelayUs<u32>>::delay_us (self=0x1000fc6c, us=500000)
at C:\Users\User\.cargo\registry\src\github.com-1ecc6299db9ec823\stm32f4xx-hal-0.8.3\src/delay.rs:69
#2 0x0000339e in <stm32f4xx_hal::delay::Delay as embedded_hal::blocking::delay::DelayMs<u32>>::delay_ms (self=0x1000fc6c, ms=500)
at C:\Users\User\.cargo\registry\src\github.com-1ecc6299db9ec823\stm32f4xx-hal-0.8.3\src/delay.rs:32
#3 0x00000318 in test_blink::__cortex_m_rt_main () at src\main.rs:40
#4 0x000001f6 in main () at src\main.rs:15
memory.x file:
MEMORY
{
/* NOTE 1 K = 1 KiBi = 1024 bytes */
/* TODO Adjust these memory regions to match your device memory layout */
/* These values correspond to the LM3S6965, one of the few devices QEMU can emulate */
CCMRAM : ORIGIN = 0x10000000, LENGTH = 64K
RAM : ORIGIN = 0x20000000, LENGTH = 128K
FLASH : ORIGIN = 0x00000000, LENGTH = 512K
}
/* This is where the call stack will be allocated. */
/* The stack is of the full descending type. */
/* You may want to use this variable to locate the call stack and static
variables in different memory regions. Below is shown the default value */
_stack_start = ORIGIN(CCMRAM) + LENGTH(CCMRAM);
/* You can use this symbol to customize the location of the .text section */
/* If omitted the .text section will be placed right after the .vector_table
section */
/* This is required only on microcontrollers that store some configuration right
after the vector table */
/* _stext = ORIGIN(FLASH) + 0x400; */
/* Example of putting non-initialized variables into custom RAM locations. */
/* This assumes you have defined a region RAM2 above, and in the Rust
sources added the attribute `#[link_section = ".ram2bss"]` to the data
you want to place there. */
/* Note that the section will not be zero-initialized by the runtime! */
/* SECTIONS {
.ram2bss (NOLOAD) : ALIGN(4) {
*(.ram2bss);
. = ALIGN(4);
} > RAM2
} INSERT AFTER .bss;
*/
openocd.cfg file:
# Sample OpenOCD configuration for the STM32F3DISCOVERY development board
# Depending on the hardware revision you got you'll have to pick ONE of these
# interfaces. At any time only one interface should be commented out.
# Revision C (newer revision)
source [find interface/stlink.cfg]
# Revision A and B (older revisions)
# source [find interface/stlink-v2.cfg]
source [find target/stm32f4x.cfg]
# use hardware reset, connect under reset
# reset_config none separate
main.rs file:
#![no_main]
#![no_std]
#![allow(unsafe_code)]
// Halt on panic
#[allow(unused_extern_crates)] // NOTE(allow) bug rust-lang/rust#53964
extern crate panic_halt; // panic handler
use cortex_m;
use cortex_m_rt::entry;
use stm32f4xx_hal as hal;
use crate::hal::{prelude::*, stm32};
#[entry]
fn main() -> ! {
if let (Some(dp), Some(cp)) = (
stm32::Peripherals::take(),
cortex_m::peripheral::Peripherals::take(),
) {
let rcc = dp.RCC.constrain();
let clocks = rcc
.cfgr
.sysclk(168.mhz())
.freeze();
let mut delay = hal::delay::Delay::new(cp.SYST, clocks);
let gpioa = dp.GPIOA.split();
let mut l1 = gpioa.pa6.into_push_pull_output();
let mut l2 = gpioa.pa7.into_push_pull_output();
loop {
l1.set_low().unwrap();
l2.set_high().unwrap();
delay.delay_ms(500u32);
l1.set_high().unwrap();
l2.set_low().unwrap();
delay.delay_ms(500u32);
}
}
loop {}
}
Cargo.toml file:
[package]
name = "test_blink"
version = "0.1.0"
authors = ["Alex"]
edition = "2018"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
embedded-hal = "0.2"
nb = "0.1.2"
cortex-m = "0.6"
cortex-m-rt = "0.6"
# Panic behaviour, see https://crates.io/keywords/panic-impl for alternatives
panic-halt = "0.2"
cortex-m-log="0.6.2"
[dependencies.stm32f4xx-hal]
version = "0.8.3"
features = ["rt", "stm32f407"]
I am new to rust embedded and maybe I have done something wrong, but I have already tried all the options I can find on the Internet.
At first I thought it was a problem with the cortex-debug plugin for vscode and even created the issue, but the guys couldn't help me because the problem is obviously not on their side.
Debugging "C" code in cubeIDE works, so I dare to assume that the problem is somewhere in rust--gdb--openocd. Perhaps I am missing something, but unfortunately I cannot find it myself yet.
I would appreciate any resources or ideas to solve this problem.
I'm hoping you checked out this resources:
Discovery - debug
From your screen-grab of arm-none-eabi-gdb it does indeed look it it did not hit the break point.
you should have seen this message afterwards:
Note: automatically using hardware breakpoints for read-only addresses.
Breakpoint 1, main () at ...
Did you compile your source with symbols, and unoptimised?
Your config all looks right to me otherwise.
I have a virtual address (instruction pointer) of the function, obtained from backtrace call. I need to figure out the debug information about it.
For example, I need the information about attach_backtraces function.
nm -a Backtrace.so | grep attach_backtraces
000000000002cdfe t _ZN2xsL17attach_backtracesENS_3RefE
The offset 0x2cdfe can be determined by substracting from PC (IP) the .so loaded address. And it matches the output from nm.
The following infrormation I get from readelf -w Backtrace.so
<3><3a14f>: Abbrev Number: 0
<2><3a150>: Abbrev Number: 161 (DW_TAG_subprogram)
<3a152> DW_AT_name : (indirect string, offset: 0x21bf5): attach_backtraces
<3a156> DW_AT_decl_file : 22
<3a157> DW_AT_decl_line : 201
<3a158> DW_AT_decl_column : 13
<3a159> DW_AT_declaration : 1
<3a159> DW_AT_sibling : <0x3a163>
<3><3a15d>: Abbrev Number: 1 (DW_TAG_formal_parameter)
<3a15e> DW_AT_type : <0x36aac>
<3><3a162>: Abbrev Number: 0
Why it's offset is 0x21bf5 and not the expected 0x2cdfe? What a piece do I miss? My next step would be query DWARF-info for the function at the offset 0x2cdfe to get debug info.
PS. I'm gathering full backtrace, where symbol name, file and line should be presented. What C/C++ library are better to use to parse/get information from DWARF ?
Addon:
No, there are no other attach_backtraces in the readelf -w output. I have found that
DW_AT_sibling : <0x3a163>
and it's definition:
No, there are no other attach_backtraces in the readelf -w output. I have found that
DW_AT_sibling : <0x3a163>
and it's definition:
<1><3f9f5>: Abbrev Number: 27 (DW_TAG_subprogram)
<3f9f6> DW_AT_specification: <0x3a163>
<3f9fa> DW_AT_low_pc : 0x2c59e
<3fa02> DW_AT_high_pc : 0x860
<3fa0a> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<3fa0c> DW_AT_GNU_all_tail_call_sites: 1
<3fa0c> DW_AT_sibling : <0x3fb21>
0x2c59e (DW_AT_low_pc) - 0x860 (DW_AT_high_pc) = 0x2cdfe (the target function address).
Is this calculation correct?
Why it's offset is 0x21bf5 and not the expected 0x2cdfe?
The offset 0x21bf5 is the offset of the name of the symbol ("attach_backtraces" here) in the .debug_str section (where the names off all types, parameters, variables and functions are collected).
That offset has absolutely no relation to the value of the symbol being represented (0x2cdfe here). These offsets just happened to be close to each other to confuse you.
What a piece do I miss?
Normally, a function should have DW_AT_low_pc attribute which represents its starting address (and the value of that attribute for attach_backtraces routine described by your output would be 0x2cdfe).
I am not sure why you are missing low_pc and high_pc here.
One possibility is that there are actually many instances of xs::attach_backtraces(xs::Ref) routine (if it's declared as inline in a header file), and the instance that you are looking at in readelf -w output was discarded by the linker (the function will appear in all object files which #included that header, but the linker will only keep a single instance of the function). If this is the case, look for another attach_backtraces in readelf -w output, with low_pc and high_pc present.
In first block of DWARF dump <3a150> (where we can see offset to function name, 0x21bf5) we also see DW_AT_declaration flag which indicates that declaration of a function was not completed in this DIE (see section 2.13 of DWARF 5 documentation).
To find the completion of declaration you should find DIE with DW_AT_specification attribute, which value is a reference to DIE which it completes (as in your 2nd block, <3f9f5>) and should have in your case value <3a150>.
Taking care on mentioned above I suppose that your 2nd block is not what you want to find since it references to another DIE <0x3a163>.
When you'll find right block, then you should use DW_AT_low_pc as a parameter you need (offset to 'attach_backtraces' from process base address).
Hope this helps.
Also, from my point of view dwarfdump tool shows a better output than readelf.
I have read https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-bar which details about PTX synchronization function.
It says there are 16 "barrier logical resource", and you can specify which barrier to use with the parameter "a". What is a barrier logical resource?
I have a piece of code from an outside source, which I know works. However, I cannot understand the syntax used inside "asm" and what "memory" does. I assume "name" replaces "%0" and "numThreads" replace "%1", but what is "memory" and what are the colons doing?
__device__ __forceinline__ void namedBarrierSync(int name, int numThreads) {
asm volatile("bar.sync %0, %1;" : : "r"(name), "r"(numThreads) : "memory");}
In a block of 256 threads, I only want threads 64 ~ 127 to synchronize. Is this possible with barrier.sync
function? ( for an example, say I have a grid of 1 block, block of 256 threads. we split the block into 3 conditional branches s.t. threads 0 ~ 63 go into kernel1, threads 64 ~ 127 go into kernel 2, and threads 128 ~ 255 go into kernel 3. I want threads in kernel 2 to only synchronize among themselves. So if I use the "namedBarrierSync" function defied above: "namedBarrierSync( 1, 64)". Then does it synchronize only threads 64 ~ 127, or threads 0 ~ 63?
I have tested with below code ( assume that gpuAssert is an error checking function defined somewhere in the file ).
Here is the code:
__global__ void test(int num_threads)
{
if (threadIdx.x >= 64 && threadIdx.x < 128)
{
namedBarrierSync(0, num_threads) ;
}
__syncthreads();
}
int main(void)
{
test<<<1, 1, 256>>>(128);
gpuAssert(cudaDeviceSynchronize(), __FILE__, __LINE_);
printf("complete\n");
return 1;
}
"barrier logical resource" are the hardware necessary to synchronize threads/warps in a thread block (probably atomic counters etc.). You don't need to know the actual hardware implementation to program them, it is sufficient to know there are 16 instances of them available.
As Robert Crovella has pointed out in your cross-post on the Nvidia forum, the documentation for inline PTX is at https://docs.nvidia.com/cuda/inline-ptx-assembly/index.html.
barrier.sync with a named barrier and thread count of 64 synchronizes the first two warps arriving at the named barrier (for compute capability up to 6.x) or the first 64 threads arriving at the named barrier (for compute capability 7.0 onwards).
Your test only launches a single thread (with 256 bytes of shared memory allocated to it), which makes tests of synchronisation instructions moot. You want to launch the test kernel as test<<<1, 256>>>(128); instead.