v 1.10.1 has just come out. Some bug fixes to do with file corruption in MX.
What I have been finding repeatedly over the last ~2 years is that when running under debug (compilation with F11) the system always breaks at some point, generally after some hours. This is with STLINK V2 or V3 debuggers, ISOL or not ISOL. PC comms with the debugger are lost. The problem is that this also kills the target.
It isn't a problem with normal breakpoint debugging but you can't have a target running for days looking for a breakpoint to get hit, because it will crash before then.
Can anyone reproduce this?
Running for days ....... I do not think it was ever intended for these kind of extreme long periods of time.
So your pc does not go to sleep after an idle period? No system updates? Your pc is running 4.5 months continuously in debug mode ? Special cabling/shielding ?
Well congratulations you must have a record there.
So your pc does not go to sleep after an idle period? No system updates? Your pc is running 4.5 months continuously in debug mode ? Special cabling/shielding ?
Well congratulations you must have a record there.
I once had a debug session abort after a colleague switched just an ac load 4 meters away from my desk. Probably emc related.
So I still would not recommend to rely on it for such prolonged periods esp. if you are for instance hunting for memory leaks that occur once a month or so. Pretty expensive if the test aborts after three weeks and you still have no data. But if it works for you perhaps you can help TS for a robust setup.
From my experience with JTAG
Hey, that's nothing! Uptime on one of my web servers:
So your pc does not go to sleep after an idle period? No system updates? Your pc is running 4.5 months continuously in debug mode ? Special cabling/shielding ?
Well congratulations you must have a record there.
I once had a debug session abort after a colleague switched just an ac load 4 meters away from my desk. Probably emc related.
So I still would not recommend to rely on it for such prolonged periods esp. if you are for instance hunting for memory leaks that occur once a month or so. Pretty expensive if the test aborts after three weeks and you still have no data. But if it works for you perhaps you can help TS for a robust setup.Hey, that's nothing! Uptime on one of my web servers:
ubuntu@qwerty:~$ uptime
00:02:59 up 1260 days, 2:35, 1 user, load average: 0.07, 0.02, 0.00
From my experience with JTAGIt is probably only SWD but I think of something that might explain the different experiences.
You can change the SWD frequency from a couple of kHz to what is it 4MHz ?
It probably makes a world of difference which debug frequencies were used, and this might also be the reason they have a max frequency defined.
So your pc does not go to sleep after an idle period? No system updates? Your pc is running 4.5 months continuously in debug mode ? Special cabling/shielding ?
Well congratulations you must have a record there.
I once had a debug session abort after a colleague switched just an ac load 4 meters away from my desk. Probably emc related.
So I still would not recommend to rely on it for such prolonged periods esp. if you are for instance hunting for memory leaks that occur once a month or so. Pretty expensive if the test aborts after three weeks and you still have no data. But if it works for you perhaps you can help TS for a robust setup.Hey, that's nothing! Uptime on one of my web servers:
ubuntu@qwerty:~$ uptime
00:02:59 up 1260 days, 2:35, 1 user, load average: 0.07, 0.02, 0.00Indeed. Run the IDE on a decent OS and you will get great uptime as well. I've had TI's Code Composer Studio running debug sessions and automated tests on a Linux box continuously for days and weeks with no glitches. And it was not a very powerful one, just a midrange machine.
Windows as a development environment is not the most suitable for the task, especially with the newer releases 10/11 that constantly harass you with updates. Unfortunately this is the OS that we need to deal most of the time due to other necessities, though.
AFAIK both JTAG and SWD use synchronous (clocked) data transfer. A single spike on the clock line screws everything up no matter what the working frequency is.
AFAIK both JTAG and SWD use synchronous (clocked) data transfer. A single spike on the clock line screws everything up no matter what the working frequency is.
JTAG has the TMS line which can be used to walk the controller to a known state. So, clock spikes are not the end of the world.
AFAIK both JTAG and SWD use synchronous (clocked) data transfer. A single spike on the clock line screws everything up no matter what the working frequency is.
JTAG has the TMS line which can be used to walk the controller to a known state. So, clock spikes are not the end of the world.
AFAIK both JTAG and SWD use synchronous (clocked) data transfer. A single spike on the clock line screws everything up no matter what the working frequency is.
JTAG has the TMS line which can be used to walk the controller to a known state. So, clock spikes are not the end of the world.But how do you know whether data got clocked in correctly? It is not about recovering the JTAG controller to a know state, but being sure that what you are transmitting is correct AND then being able to recover. The latter isn't trivial (to say the least) when you are feeding a CPU instructions to access the memory. An extra (or missing) clock means you are suddenly clocking in a different instruction or address.
JTAG is nothing more than 2 simple shift registers which have next to no functionality in them.
All the actual intelligence & complexity that is hard to recover errors from sits below JTAG.
Where it comes to MIPS you are basically feeding instructions into the CPU one by one into some kind of a virtual memory area.
Where it comes to rock solid remote debugging over JTAG or SWD it comes down to getting the signal integrity right before anything else.
(nothing in the data sheet)
Actually I think the 32F437VGT7 has 2MB FLASH while a 32F437VGT6 would be 1MB but it is very hard to establish the part numbers (nothing in the data sheet)
Flash memory size
G = 1024 Kbytes of Flash memory
I = 2048 Kbytes of Flash memory