I was using a dht22 sensor in my raspberry pi pico w board but suddenly I can't anymore
I get the following error when trying to import dht module:
ValueError: incompatible .mpy file
I tried updating the micropython firmware to the latest version but the problem persists.
My DHT22 module is a bit faulty since I connected it backwards the first time, but it was working ok, sometimes it emits a high pitched noise, but after reconnecting it it worked normally, now It emits the sound constantly.
However the error appears regardless of the sensor being connected or not, just by calling "import dht" without any extra code.
The rest of the functions of the board are still working, I can blink the led, drive a relay module, run a web server, all the other functions of my application work normally.
After looking at the files loaded in my board an extra file was present:
dht.mpy
The file had contents from my log function (a function I use to write exceptions to a file)
I have no clue how this happened, but deleting it solved the problem
Related
here is the problem I'm searching for help for: I've created an example program for testing BLE advertisement using exactly the source found in:
https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/tests/BLETests/SampleServer.cpp
with a tiny addition of prints to make program progress visual.
When running the single file in Arduino it works perfectly as expected.
However, building it with vscode & platformio with the right setup, the program waits forever.
The right setup means correct board & Arduino platform selections which work perfectly for me for lots of other functionalities (BLE, WiFi, etc).
Following is the line where the program is waiting forever:
Thank you.
The code to run when compiled with VScode PlatfromIO
This is a question for people familiar with the Nucleo H745ZI, or H7 in common.
When I received the Nucleo H745ZI it had the blinking LED program on it. This was working fine.
Now I'm trying to upload my own program and it's not doing anything at all. Both the LEDs and UART aren't giving output. This is after generating a fresh project in CubeMXIDE. Everything default.
My code;
HAL_GPIO_TogglePin (GPIOB, GPIO_PIN_14);
HAL_Delay(50);
HAL_GPIO_TogglePin (GPIOE, GPIO_PIN_1);
HAL_Delay(100);
HAL_GPIO_TogglePin (GPIOB, GPIO_PIN_0);
HAL_Delay(200);
uint8_t buff[4] = {3, 4, 5, 6};
HAL_UART_Transmit(&huart3, buff, sizeof(buff), HAL_MAX_DELAY);
I've tried both building and manually uploading the CM7.bin file and using the debug tool in the CubeMXIDE. Both not working.
Firmware has been updated.
By the way, does anyone know where I can find this default program?
Found solution for NUCLEO-H745ZI-Q:
Do not drag and drop CM4 or CM7 bin file in Nucleo board storage. Use STM32CubeIDE to upload program to each one. Use default NUCLEO-H745ZI-Q board settings when creating new projects. You only need to connect ST Link USB.
When we are working on NUCLEO-H745ZI-Q remember that we have a dual core architecture so we must configure the peripherals for each core in the CubeMX project or in the Cube IDE configuration window on the tab of System Core > GPIO for the LEDS and the same for UART
Once you have generate the code, then you'll core M4 and M7 subproject directory whit their own source and main.c files.
Also, on my experience, I have notice that you must compile and upload both core-main.c-program to run your code on board, specially when you program at core M4 because the code uploaded does not execute until you upload M7 program.
I have the following problem. Once i generate Keil project using ST CubeMX and write project into STM32F103C8 MCU, everything goes well; However, after this first flashing i'am not able to flash it anymore as it throws the following error:
Error: Flash Download failed - Target DLL has been cancelled
I have pulled Boot0 pin, activated it, and erased MCU. This procedure helps only for one time flashing; however, if i flash MCU with bare metal or CMSIS code (which was not generated by CubeMX) it works fine and i can flash as many times as i want without errors.
Could you please advice, what could be wrong and how can i fix this?
Problem was in default configuration of STM CubeMx. In System core -> Sys Debug was switched off by default. After i changed it to Serial Wire it worked.
I am attempting to upload my written program for the STM32F411RE from my TrueStudio for STM32 IDE to the board itself. The board is connected via the mini USB b cable and the intent is to program it via SWD.
Setup
Atollic provides a nice tutorial on how to perform this programming via it's TrueStudio IDE and the ST-Link_CLI (Command Line Interface), as described in the document at this link. This requires the following steps, which I have followed and checked multiple times:
First and foremost the output (binary) file needs to be an intel .HEX and
not the TrueStudio .elf default. To change this go to Project properties -> c/c++ build -> settings -> tool settings tab -> other -> Output format
and tick the option 'Convert build output', ensure that the Intel Hex
option is selected in the dropdown.
To call the ST-Link_CLI from inside the IDE requires making an external
tools configuration. To make this config I go to Run -> External Tools ->
External Tools Configurations .... and create a new configuration, lets
call it ST-Link_CLI. For the Working Directory I specify the directory of my ST-LINK_CLI
(C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility)
whilst for the Location I specify this directory and the file name
(C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK
Utility\ST-LINK_CLI.exe).
Lastly, I add the following parameters to
identify the STM32 board, have it connect via SWD and under reset, whilst
telling it to upload the .HEX file built by TrueStudio
(-c ID=0 SWD UR LPM -P ${project_loc}\Debug\${project_name}.hex -v).
Output
When I then call this external tool configuration via the Run -> External Tools -> ST-Link_CLI link just created I get the output listed below:
STM32 ST-LINK CLI v3.4.0.0
STM32 ST-LINK Command Line Interface
ST-LINK SN: 066EFF525750877267092042
ST-LINK Firmware version: V2J33M25
Connected via SWD.
SWD Frequency = 4000K.
Target voltage = 3.3 V
Connection mode: Connect Under Reset
Reset mode: Hardware reset
Debug in Low Power mode enabled
Device ID: 0x431
Device flash Size: 512 Kbytes
Device family: STM32F411xC/E
Loading file...
Unable to open file!
Clearly the ST-Link_CLI is succesfully called from inside the IDE, but it somehow cannot digest the .hex file (inside the debug folder) and upload it to the STM32 board.
Even flashing a completely new generated project from CubeMX and setting the options above (including setting it to a .hex file) will not let this toolchain upload it to the board.
Manual code flashing
I have been able to succesfully upload the .HEX file built by TrueStudio via manually uploading it to the STM32 Board with the use of the ST-Link GUI, so I do not think the problem is in the ST-Link itself. I cannot however debug it in this manner, since I need the TrueStudio IDE tools for that and thus need the external tool configuration to work succesfully.
Instead I suspect the issue lies with my own setup, where is somehow is missing a call or has an option set incorrectly. It could also be that the GUI and CLI clients operate in a completely different fashion allowing one to read and upload the file whilst the other cannot, but that seems unreasonable to me.
I am kind of at a loss here however, as I cannot seem to figure out why others can make this work via the provided Atollic documentation and mine is throwing up these errors.
You try to reinvent the wheel using the triangle.
Everything is configured in the TrueStudio:
Just in add the debug configuration and you are done.
What benefits would OpenOCD offer at this point
One essencial : debugging
given how much I have already learned about TrueStudio?
This knowledge (how to configure external tools etc) is rather useless in 99.9999% of circumstances. It is only the configuration of the Eclipse. Not too complex actually needed here.
In regards to my own code, I have not been able to get the ST-Link_CLI to work as an external tool the way I intended, [but I have been able to get the STCubeProgrammer (CLI) to work in the same respective manner as I was attempting to do with the ST-Link].(http://gotland.atollic.com/resources/applicationnotes/AN1801_cubeprogrammer_in_truestudio.pdf).
Seeing as I literally used the same procedure as before but instead specifying the location and executable for the STCubeProgrammer (rather than the ST-Link), I suspect the issue may indeed be the ST-Link CLI (connection to TrueStudio).
It now uploads successfully and immediately after boots me into the debug environment of TrueStudio :)
I simply commented "load" command in the startup script and debugging worked. I only had to load the hex using the st link first.
/# Load the program executable
#load <---//added "#"
I am using Petalinux, built with Yocto SDK. I want to automatically install my kernel module and make the devices available in /dev/*.
With KERNEL_MODULE_AUTOLOAD+="modulename" I can see the appropriate entries in /etc/modules-load.d/ as well as entries in /sys/class/misc/** , but not in /dev/*. Is there something I am missing?
Well, the structure of Yocto has nothing to do with the creation of device nodes. Either your driver does that for you (upon loading / probing), or you had some script that made them earlier. As long as your module has been loaded upon boot, you've got KERNEL_MODULE_AUTOLOAD correctly. If the module gets loaded, but you're not getting any device nodes automatically (and you got that before) you'll need to investigate what has changed in your system. (Versions of kernel and eg mdev/udev etc)