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.
Related
I am using cubeIDE version 1.8.0 and NucleoF746ZG microcontroller for my project. I have made the codes and when I compile and run they work properly without errors and warnings. But the problem is that when I try to debug, It doesn't work. I mean the debug code uploads to the board but no cursor shows up at the breakpoints. I have tried to make some breakpoints and hault the program at them but no cursor comes to them.
I have opened a trace control tab and it says "Tracing is not supported". I don't know why that happens. The only thing that I know is that after installing the software, It didn't recognized my st-link. It was fixed after replacing the libusb-1.0.dll to a newer version of it. That was the thing that I have changed. But I don't think that it will affect since compiling and running works properly.
If anyone has encountered this issue or if you have any clues about a cause for this matter, please let me know. And request me if you need any more details from my side. I have attached two screenshots for reference.
Thanks and Kind Regards...
Screnshot1
Screenshot2
I have a GCC 3.4.3 toolchain built for ARM (arm-elf) here in my Windows 7 (64bits) setup. We use this to build our software product to a specific hardware.
Recently, we have been experiencing some problems with this particular toolchain.
First, when we try to call arm-elf-gcc to build each source file (there are lots of them), it complained about it not being able to allocate enough heap.
Then, I thought it was some problem with the outdated cygwin DLL distributed by the hardware vendor. So I replaced it with a more recent version (1.7.35). The problem stopped and the build does go ok but now it is incredibly SLOW (it took about 40s to build a single .c source file).
Does anyone has experienced this problem before? How can I debug and fix it?
Thanks in advance.
Sounds like you have had a similar problem to me and might be worth trying this. When i first encountered this, I had to install cygserver and then run this (make sure you right click admin):
Previous solution
However, the problem resumed and I simultaneously couldn't install/uninstall some problems. Eventually I resolved this by terminating SearchIndexer.exe in Task Manager. Indeed, I have gone in to Control Panel / Searach Indexing and pulled it back from doing any indexing. My installation taking 1hr took 3 more seconds. The change to Cygwin was instantaneous.
Cygwin is now flying!
I've had an issue with slow execution of builds for a while on cygwin, using make and a proprietary compiler that "isn't gcc, honest...", but has very similar error returns.
I was forced to update yesterday and ran into the issue of rebaseall simply failing to execute. This forced me to dig into other things and I found a report that Trusteer Rapport/End Point Protection has been known to cause issues with rebaseall,and slow response times. So I removed it. This fixed the rebaseall, but has also massively increased the speed of my build. Worth checking to see if you have it installed, try removing it. AV packages in general are reputed to interfere and may be the cause.
first off, I really need to make a 64bit version of glfwdll.a and glfw.dll (so I can hopefully finally succeed in getting the Go glfw bindings to work under Windows ... was a breeeeze under Linux!)
Seems like I now succeeded in compiling 64bit versions of glfwdll.a and glfw.dll using mingw64, MSYS and their make scripts, even though I did get a couple of error messages along the lines of "maincrt entry point not found, using default 0xsomehexnumber instead" or some such. Entry points of course refer to executables, in this case those in the examples directory.
And indeed, most of them don't work! All got built however. The following executables work:
listmodes.exe mtbench.exe mthello.exe and particles.exe -- the latter being the only graphical (3d gfx) example working for me (the former ones just outputting some test infos onto the console window).
Now what's the issue with the other ones? They don't crash, they don't report anything to the console... I run them, they return immediately, silently.
Is my GLFW build broken? How to fix? What's the big difference between the 4 examples that work and the others that don't?
This is a fairly new, vanilla Win7 64bit installation. No crapware, everything up to date, UAC and Themes are off, not a lot of software installed at all, Nvidia GPU driver updated (GPU Caps Viewer and the likes run fine, so OpenGL is there).
I'm not yet allowed to add comments, so I'll post this as an answer.
The issue you're having is due to three separate bug in GLFW. I fixed them today and the fixes will be included in GLFW 2.7.6. Until then, you can use trunk from the GLFW Subversion repository.
To be sure that you really have no DLL-hell issues with the opengl32.dll, glu32.dll, glut32.dll etc., check out the Event Viewer tool and see if there are some warnings or errors for you app.
This is my thought because you are only able to run the mtbench and mthello which have nothing in common with the "real" OpenGL API.
No clue about particles.exe though - maybe GLFW checks for errors internally and call the exit() routine ? Check the %errorlevel% also.
Also take a look here:
http://glfw.svn.sourceforge.net/viewvc/glfw/trunk/examples/pong3d.c?revision=1110&view=markup
There is a GameMenu() function which may exit silently if "!glfwGetWindowParam( GLFW_OPENED )", which obviously means that OpenGL was not initialized.
The same function serves as an exit flag here
http://glfw.svn.sourceforge.net/viewvc/glfw/trunk/examples/wave.c?revision=1110&view=markup
Once again, double-check the DLLs !
I believe that you are experienced not to make "advanced" mistakes in the build process, so there just might be some funny thing happening at the "user level".
And another suggestion:
http://sourceforge.net/projects/glfw/forums/forum/247562/topic/3868944
Some parameters might not work exactly for you.
To "fix" the samples try commenting out the glfwGetWindowParam call.
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.