I just tried out the new STM32 Cube IDE, which based on Atollic True Studio which based on Eclipse.
Looks good, Cube MX is integraded but the Debugger / ST-Link Intigration made problems by me.
If I flash a MCU for first time, it works pretty well. But on next time, the IDE says
"Target no device found
Error in initializing ST-LINK device.
Reason: No device found on target."
I found out that the ST-Link V2 with my Hardware need a "Connect under Reset".
With the ST-Link Utility it works fine, but in Cube IDE I cant find that point to set up.
Here is the Config Form: IDE
Can anyone assist?
I found the problem of the code, why the upload just works one time after full erase:
Cube IDE generate the HAL_MspInit() in ..stm32f1xx_hal_msp.c which contains:
__HAL_AFIO_REMAP_SWJ_DISABLE();
With that all debug stuff will be disabled after first flash.
With changing this line to:
__HAL_AFIO_REMAP_SWJ_NOJTAG();
The Debug mode works fine and several times in a row.
With version up to v1.0.1 it is not possible to connect under reset with STM32CubeIDE from GUI.
The reason(s) why you are having the issue could be:
You are using low-power features where CPU is halted
You are overwriting default alternate function setup for SWDIO and SWCLK pins (PA13 and PA14).
If you need to use Connect under reset, use STM32CubeProgrammer for flashing. Even better, try not to use sleep modes or do not overwrite flashing GPIOs for the test.
Related
I am using windows and I installed the Arduino IDE from Microsoft store, but I wanted to code everything in VS Code. When I want to run the program or select the board it just says this:
Cannot find Arduino IDE. Please specify the "arduino.path" in the user settings. Requires a restart after change.
How can I fix this, where can I find the arduino.path?
Install PlatformIO extension for VS Code. It has Arduino framework and it works with all possible boards, and then some.
For me nothing could make Arduino IDE.app (2.0 beta) work. Switching to 1.8.6 (Arduino.app), putting that into my Applications folder (so the path is /Applications/Arduino.app) and setting the VSCode setting to:
"arduino.path": "/Applications/Arduino.app"
Fixed this error (and got me to select a board, which I was able to do with the command palette. Make sure to open the new non-beta Arduino.app and add any existing board manager jsons, such as esp32 in my case, that might have already been added to the beta Arduino. The libraries appear to already be in place.)
I also had to add this to my C/C++ settings for includePath:
${workspaceFolder}/**
/Users/<owen>/Library/Arduino15/packages/esp32/hardware/esp32/1.0.6/**
At this point "verify" began working. It was still pretty slow, and flashes the Arduino splash screen while running, so I'm now going to follow the platformIO advice and see if it's any better.
P.S. At first I also got an error about [Warning] Failed to generate IntelliSense configuration but think I fixed this by clicking the "don't show again" or similar on the popup that appeared in the lower left. (Similar errors show up on syntax issues, so could be related to that instead.)
I guess I'm having a basic understanding issue regarding the nodemcu/ESP8266 when it is used with the Arduino IDE and/or visual micro (for MS Visual Studio).
Everytime I upload a program/sketch which is obviously written in C in this case, it is compiling and uploading a binary of about 280kb, even if it is only a simple "blink" example.
Is it some kind of firmware being uploaded everytime or is it just monsterious libraries needed for the ESP to work with the Arduino IDE?
If it is firmware, do you normally "update" the firmware to a more recent build when working with the Arduino IDE? When using the nodemcu LUA firmware, there are periodic updates.
Thanks!
Basically, you build the firmware, which is a combination of your own code, and lots of other code/libraries.
All the other parts are part of the Arduino ESP8266 core, which does indeed get updates (it lives here: https://github.com/esp8266/Arduino). And it itself contains the Espressif SDK, which also gets updates (https://github.com/esp8266/Arduino/tree/master/tools/sdk).
Like NodeMCU you can get periodic updates, but they are of the core, and the only way to get them into your firmware is to recompile your sketch.
This is completely normal - When writing code for an interpreted language like Lua for the ESP/NodeMCU, you're just uploading what is a relatively small text file(s), as the code needed to run it is already on the chip, and doesn't change.
However, when you start working with compiled languages like C (With the Espressif SDK only, for example), or C++ with the Arduino IDE, you are replacing the entire firmware each time your code changes. This includes the TCP/IP stack, WiFi management, the logic controlling the PHY/MAC interface, the mini OS, and a host of other bits to make your ESP8266 work. Even if your code appears to be just a simple "blink" sequence, there's a lot of code running behind the scenes to make it possible, leading to the large sketch size.
Generally, every change to your sketch code will produce a complete copy of everything needed to create a bootable, runnable binary for the ESP8266. This is what is causing the 280KiB file. Since each copy of your code includes the newest (Or at least whatever is in your IDE at the time) copy of the system level code, there is no separate update process - Each time you upload your sketch, the system code is updated too.
Additionally, there is some extra overhead from the Arduino abstraction on the Espressif SDK, leading to a larger resulting binary size.
Followed the instruction at http://processors.wiki.ti.com/index.php/SensorTag_with_iBeacon.
The iBeacon-enabled firmware was created with IAR and updated with OAD from iPhone but SensorTag stopped working after the update. No advertising, no LED blink by the side button.
I tried same/similar things several times and also tried directly upload the firmware from IAR IDE via CC Debugger but no luck.
I can put it back to the previous working state by uploading downloaded firmware with the flash programmer.
I also tried to compile the standard firmware (SensorTag with no iBeacon from the BLE stack) by myself with the IAR but it didn't work, neither.
So I think the compiling in IAR is my problem but the make could finish successfully. No code was changed by myself. (only the _NR_OF_VIRTUAL_REGISTERS to avoid a linker error).
I wonder if there are anyone who successfully made it work by following the instruction on the above URL.
Firmware for iBeacon: SensorTag_Beacon_Patch_1v0
CC Debugger's FW:0041
SensorTag: CC2451, 1.4.1, 1407
IAR for 8051 version 8.30.3
BLE stack: BLE_CC254x_140.zip
Working standard firmware version: 1.5 A & B
If I could get any suggestions or advises, it'd be appreciated.
Thanks and regards,
Thanks for comment, Chris.
I found a solution on TI E2E community.
IAR 8051 V8.30 has a problem since updated from V8.20. It was reported as "8051 V8.30 linker Error[e16]: Segment ISTACK is too long for segment definition" (http://supp.iar.com/Support/?Note=95811).
After modifications to .xcl linker configuration, the build ran OK without any errors.
But the firmware didn't work on SensorTag.
One of the post on TI E2E Community mentioned that changing the Number of virtual registers in the "Option" settings from 16 to 12 worked with IAR V8.30.3. Then tried that with an original .xcl file (not modified one). No error during build and worked on SensorTag too.
There are 3 packages in the SensorTag_Beacon project, that are CC2541DK-Sensor, CC2541DK-Sensor-OAD-ImgA and CC2514DK-Sensor-OAD-ImgB.
What worked are only CC2541DK-Sensor with Number of Virtual Register in Option set to 12 and without .xcl file modified.
CC2541DK-Sensor-OAD-ImgA and CC2514DK-Sensor-OAD-ImgB didn't work with any combinations of the Option setting and .xcl modifications.
Hope this helps to anyone else in the future.
Regards,
I have purchased the CC2540 EK I am trying to program the SampleBLE peripeheral onto the CC2540EM. I am using the IAR tool chain and the USB cable is connected directly to the SMARTRF05EB (not using the CC debugger) In IAR I can download the code but the SimpleBLEperipheral does not seem to run.
Looks like the App that came with the CC250EM from the factory has been erased and I am unable to reload that application again.
What is the exact project workspace that I shoud open?
Are there any changes that need to be made to the IAR project so that it can be run on the CC2540EM?
The IAR project name is SimpleBLEPeripheral - CC2540DK- MiniKeyfob - this seems to suggest that it is meant for the keyfob and not the CC2540EM.
It's due to the build option.
You got to set the build option to "cc2540", instead of "cc2540df-mini keyfob"...
In IAR, you can set the build option in the drop-down menu in the Workspace area. (it's right under the word "Workspace")
After doing this, compile and reload the hex file to the module.
It should be able to solve the problem.
I would like to change the output mode of an Intel GMA450 based graphics chip to "cloned" mode.
Since the environment is a Windows Embedded Standard and only one of the connected monitors might be visible for the enduser, I would like to either permanently set the output mode to cloned or reset it continuously to cloned mode in case the actual mode differs (e.g. after a reboot, disconect/reconect of the second monitor or by other means).
Is there a way (Registrykey, API for the Intel driver, Win-Api) to change the display mode to cloned / dual output programatically?
Update:
I found the SDK for the IEDG driver it seems that I might be able to programatically set the resolution, clone mode etc.
However, I can't find the SDK or any information for the driver I am currently using: Intel® Graphics Media Accelerator Driver for Windows* XP, version 14.32.4.4926.
This isn't a good answer, but it might get you headed in a direction to figure it out.
My last laptop had an external monitor connected, and the Intel drivers would often be confused about the orientation of the secondary after a reconnect or a reboot. I got tired of dealing with that and tried to fix it programatically because the clicks were too many in the GUI. Select this monitor, select rotation, select other monitor, select rotation, apply, arrange, apply, wait...
I spent about a day on it (ahh, the days of being an employee vs. self-employed!) and the solution I found was to use a program to compare the registry (regshot perhaps?) to discover what keys were involved in the correction (what they were before versus what they were after) and then there was an intel-provided exe that forced the driver to reset based on the registry-- the exe was essentially like pressing the "apply" button in the gui. I was running XP and if I recall, the gui management was for configuration of the Intel Graphics Media Accelerator Driver for Windows XP as well. So the final solution became a cmd file on my desktop that would apply a REG without confirmation and then run an exe with some parameters.
Now, I don't have that laptop (they didn't let me walk out the door with it when I quit!) and I do not remember the specifics on the exe that was required to do the reset. Just changing registry keys didn't spontaneously cause it to take effect-- there was an api call involved, which I just handled with their exe. I know that isn't a lot to go on, but something tells me the file was in the driver package, or somewhere on the drive already, and I just found it. Running it at the command line gave options. Like /reset.
I hope that helps you a little. Be sure to post back if you figure it out.
Also post back if I'm completely mistaken and it didn't happen like this at all. But that's the way I remember it. :)