DevHeads IoT Integration Server
The DevHeads IoT Integration Server accelerates technology engineering by helping pro devs learn, share and collaborate.
JoinDII
DevHeads IoT Integration Server
The DevHeads IoT Integration Server accelerates technology engineering by helping pro devs learn, share and collaborate.
Joinseeking-collabs
firmware-and-baremetal
middleware-and-os
edge-networking
pcb-and-analog
jobs
iot-cloud
code-review
devheads-feed
general-dev-chat
Unexpected Memory Value Fluctuations in GDB While Debugging Pointer in x86-64 C Program
In my last question, I misunderstood how GDB interprets memory when using different formats like
x/d and x/1wd. After some digging, I realized the issue was related to GDB displaying the same memory contents as both signed and unsigned integers. That cleared up the confusion about the "flipping" values.
Funny how I am facing a different issue with pointer manipulation and register inspection. I’m debugging a simple C program where $rbx is pointing to dynamically allocated memory. Here's the setup in my main.c file
When I inspect $rbx in GDB, I expect it to point to the buffer and show the correct values as 28 and -5604 for ptr[0] and ptr[1]. When I execute these commands, I get some strange behavior which I logged in bash.txt
. Been making use of x86-64, GDB version 10.1...
How to prevent ADC interrupt from affecting LCD display on AVR MCU?
I am working with an AVR MCU and have encountered an issue with an interrupt routine affecting my LCD display. Specifically, I have an analog potentiometer connected to an analog pin, and the interrupt associated with the ADC conversion seems to be interfering with the LCD_display method. I need to ensure that interrupts are paused while executing the LCD update code to avoid conflicts.
I used
cli() to disable interrupts before updating the LCD and sei() to re-enable interrupts after the update is complete. This prevents the ADC interrupt from interfering with the LCD display operations.
Is there a better way to manage interrupt handling without affecting the LCD display? my code snippet is in the attached file....Solution:
Hey man, If you want to effectively handle interrupts without impacting your LCD display, You could try a few things like ;
Using atomic blocks for critical sections management & making sure that the updates of your LCD screen happen in the main loop only by flagging them with an ADC interrupt.
I hope this helps @Dtynin...
Issues with STM32L476RG Nucleo Board Not Detected in CubeIDE on Ubuntu
Some time ago, I developed basic firmware for STM32 using CubeIDE on Windows. However, I have since switched to Ubuntu and recently downloaded version 21.04 of the operating system.
Upon purchasing a new STM32L476RG Nucleo board, I proceeded to install CubeIDE version 1.6.1 onto my Ubuntu operating system platform. Following the creation of an uncomplicated LED blink program using said software application, I attempted to debug its execution by pressing F11 but was met with an error message: "No ST-Link found."
This occurs because at that point in time there was no physical connection between the aforementioned STM32 Nucleo board and my USB port present. Subsequently after remedying this issue through their union and initiating debugging once more; while each preceding programming step completed successfully during compilation as well build phases respectively - finalization instead failed due in part to resultant errors received containing verbiage identical or similar-to=the following: ...
Solution:
Hey @Sterling check the USB Permissions first , you need to ensure that your user has permission to access USB devices, so add your user to the dialout group
Run this command in the terminal
```
sudo usermod -aG dialout $USER...
Issues with Configuring ITM Output in Atollic TrueSTUDIO for STM32L4
Currently, I am utilizing the Atollic Truestudio IDE (which is based on Eclipse) to create firmware for different STM32L4 Nucleo boards. To date, my approach has involved employing
printf through a Virtual COM port linked with UART.
I now intend to transition towards utilizing printf alongside STM32 ITM.
My focus is on the Nucleo-L4A6ZG board, which utilizes a gdb server for debugging purposes....
Troubleshooting SPI Communication Between STM32G431RB Master and F446RE Slave Boards
I am trying to establish communication between two Nucleo boards (STM32G431RB as master and Nucleo F446RE as slave). I used the example codes from the STM32 GitHub page (NUCLEO-G431RB/Examples/SPI/SPI_FullDuplex_ComPolling_Master and STM32F411RE-Nucleo/Examples_MIX/SPI/SPI_FullDuplex_ComPolling). I made some changes to the slave code, including GPIO settings, but the communication still doesn't work. I chose NSS as [ hspi1.Init.NSS = SPI_NSS_SOFT; ]. The codes also include LED configurations as mentioned in the README files, which indicate an error based on the LED status.I know I have an error acording to led 2 but I don't know the problem.
LED2 toggles slowly when there is a timeout or an error in transmission/reception process....
How to Safely Modify .byte Values in x86_64 Assembly Without Segmentation Faults
I need to modify specific
.byte values using the inc instruction in a small x86 64 asm project . I want to increment the values of .byte 0x0d and .byte 0x04 in my code to change them to .byte 0x0f and .byte 0x05, respectively.
I expect to increment the .byte values by using inc byte ptr [rip+offset] to modify the bytes at the correct memory offsets. So when I run the code, I encounter a SIGSEGV, a segmentation fault at the inc instructions, even though I verified the offsets using objdump and confirmed that they are correct
I also tried using:
```
lea r11, [_start]...Solution:
You're getting a
SIGSEGV because .byte values are in the code section, which is read-only. You cannot modify them directly with inc. store them in a writable data section like .data or .bss, then modify them using the correct addressing mode.