while i was using cubemx to set peripherals of my stm32f407 arm core, just before generating code, i checked and selected the "set all free pins as analog (to optimize the power consumption)" dialog box in project settings-> code generator-> HAL settings, without masking the debug pins (swdio and swclk). After that, i downloaded a simple blinky code inside the microcontroller successfully using keil ide. but now when i want to use keil to erase or download a code, i see "no target connected" error in debug tab and i cant download any code. How can i solve this problem? Thanks for your helps.
After about 10 hours searching, i found the solution.
if someone had the same problem, here is the solution :
https://electronics.stackexchange.com/questions/204996/stm32-st-link-cannot-connect-to-mcu-after-successful-programming
As an addition to your answer - when you set all as analog, set in the SYS the correct debug interface. It will prevent code generator from setting those pins as analog.
Related
I'm trying to debug my application with the Segger J-link since the ST-Link debugger that comes with the Nucleo dev board allows only 5 breakpoints.
I cannot find a way to stop the watchdog during debugging sessions. Where can I find such setting?
If I use the ST-link for debugging this option is available in the following window:
but, when I select J-Link, that option is not there anymore:
I found something on SO about adding specific instructions (Disabling the STM32 IWDG during debugging), but I'm looking for something that does not require to add code.
but I'm looking for something that does not require to add code
The answer is:
Easy way: change the IDE.
The moderate way: amend the debug startup script (https://wiki.segger.com/J-Link_script_files)
The hard way: rewrite the debug plugin
Edit : Problem circuvented by generating a Makefile project but I'd still like to know what is going on.
This question echoes my unresolved problem mentioned here (STM32 app not running sometimes, remains in DFU).
I have a custom board STM32L486 based and I am using the built-in DFU mode to upload new firmware over USB using dfu-util on Linux.
Sometimes, for unknown reasons, the app won't start after leaving the DFU mode.
A slight change in code can make it work or break it. (see link above for details).
Examples of changes that can reverse the problem :
Adding / removing a HAL_Delay or a LED Blink
+1 or -1 on an array size
Adding / removing a sprintf format
What seems to work is building the binary with Og optimisation (or using the STLink tool and debug mode).
I have tried to increase the heap and stack (up to 20x the default), it doesn't change anything.
Checking the prepare dead code/data removal options in Atollic seem make build fail more than other times.
What could be causing the issue of the app not starting, not even the init steps ?
How can I track down the culprit flags that may cause this ?
Can this be linked to a memory alignment problem ?
Any ideas / insights / comments on how to check is welcome.
I have been able to reproduce the same issues (from here and my other link) on a Nucleo board.
I tried to generate a Makefile project from CubeMX and the problem does not happen. I guess this is a bug in either the binary generated by Atollic or the compiler/linker settings that the IDE.
Note that my Makefile uses the exact same toolchain as Atollic so this cannot be a toolchain issue.
This issue is hereby circumvented by this, but I'd still like to understand what may happen.
As far as I've tried, this DFU issue and app not rebooting is caused when building from Atollic (TrueStudio).
Generating a Makefile project from CubeMX solved this issue though I still cannot explain why.
I am wondering which debugging tool I can use for an assembly program and how to use it.
I have written a simple bootloader in assembly. However, it is not quite working properly as I wished, even though I think the logic is correct. So, I am trying to use a debugger so that I can step through the bootloader, checking the register status and etc.
I tried GDB on Ubuntu, compiling my .asm to .elf and .o (Do I need to do it? If yes, what is the next step?) Also, I read that there is an internal debugger in Bochs simulator, but I can't quite find any document how to use it. I also have Visual Studio 2010, windbg, but I don't know how to use it for .asm file debugging.
If you have done this before, it would be an easy answer. Any help would be really appreciated.
Sincerely
If you want to debug bootloader code, you obviously need to run it in the same environment that the code itself is going to run in. As I'm sure you already know, bootloader code is executed in real mode once the BIOS finishes doing the POST. The bootloader is then loaded into memory at 7c00h and a jump to that address is executed.
Obviously, this kind of environment cannot be reliably emulated once you've got your computer running and a "real" operating system already loaded, since by that time your CPU is in protected mode (or long mode, if it's AMD64). Your only option at this point is to use QEMU or Bochs in order to emulate a real PC inside your operating system. I've used Bochs to debug some bootloader code I've written in the past and it worked quite well. Check the manual pages for more detailed instructions.
I am bit new to this field and my query here is a bit vague. I am particularly interested in how any of you, who have had experience with uBoot and a JTAG debugger (like a Lauterbach), have gone about tackling and resolving an issue within uBoot.
Specifically, I would really appreciate if you could describe the problem encountered within uBoot, and how did the JTAG help you resolve the issue.
Thanks,
vj
I have used this many times using Texas Instruments' CCS debugger. I would create a dummy project with the u-boot source code and then attach. Afterward, I can load the u-boot symbols or the u-boot app itself and step through the code. Reloading and restarting u-boot is helpful to work through issues.
This applies to any problem with u-boot, including start-up problems.
I use LPCXpresso (based on Eclipse) to debug U-Boot on my board (with LPC4350 MCU).
But be careful, you could have problem to debug and you maybe need to modify the .lds file (linker script).
You have to find this file but be cautious, the file is copied and modified when you configure the compilation for your board, you have to look for the original file.
Then if you find
/DISCARD/ :
{
*(*)
}
in the .lds file, you won't be able to debug. Just remove it or comment it.
I'm just getting started learning FreeScale DSCs (MC56F800x series). I've done some work with AVRs using both AVR Studio on Windows and Eclipse and avr-gcc on Linux. CodeWarrior is just not as intuitive.
Right now I'm stuck trying to debug a simple program. I start the debugger using the built-in simulator, but it never reaches the first line of main(). Instead it seems to get stuck in some initialization code (MC56F8006_init.asm), specifically this line:
;; Loop until OCCS_STAT[LCK0] = 1
wait_for_lock:
brclr #OCCS_STAT_LCK0,x:>OCCS_STAT,wait_for_lock
I've let it run for quite a while and it never gets past this. It's obviously waiting for something, but what? You would think the simulator would just work... argh. Maybe there's some options I can change to make it pass this step?
I'm going to keep digging and will post an answer here if I find it first.
Updates:
Here's what I've found:
OCCS
On Chip Clock Synthesis
brclr
Branch if Bits Clear
The instruction loops until OCCS_STAT LCK0 is set. This register means the on-chip oscillator's PLL has locked (waits for clock stabilization).
I'm still not sure why the simulator spins forever on this line, and how I can solve this without resorting to hacking up the init code (which is part of the code library and not within my project).
I am not familiar with the part or the simulator, but it seems likely that the simulator is instruction-set-only and does not simulate the PLL hardware.
In most embedded development systems, the run-time startup code is provided as source and you could modify it (or rather make a local copy in your project and assemble and link that to override the default start-up). Alternately you could simply place a breakpoint in this loop, and advance the program-counter register to get it out of the loop. In many debuggers it is possible to attach a script to a breakpoint to do this automatically.