Just upgraded to 2.51. Downloaded the new bootloader and firmware without any problems, but then the problems started. The unit seems to get stuck in bootloader mode most of the time (my assumption, as it doesn’t react to ATI command). I need to close the port, pull the power on the unit and reconnect and then open the port again. About one in five times, the module would be detected and I’d be able to run a few AT commands. I’ve been able to downloaded an application once, and it ran, but I cannot start a debugging session because of timeouts. Refreshing, resetting the device and most other operations result in timeout errors.
The one strange thing I’ve noticed is in the target port view, UART1 is not linked to COM4 as it should be. Reopening the port or restarting DS sometimes fixes this for a short while, but after a few operations, the timeouts occur again.
Any suggestions?
Edit: Was a bit tired, forgot to add this:
-Unit: SL6087
-DS: 2.2.0.201205091434-R9457
-Bootloader: V09c09 (7.51)
-FW: 7.51
Serial port: Prolific Serial to USB converter.
We have observed some similar behavior concerning FW 7.51, which was sometimes failing to handle correctly a GDB session.
We’re currently investigating on the topic, trying to understand what is the root cause, and try to get a workaround.
Will keep you informed.
Not sure if it is related, however not having much luck with EAF 2.51. Firmware is updated OK, but when trying to load a simple “Hello World” binary, it fails. Same installation but based on EAF 2.3x works 100%.
[attachment=2]Target_Info.jpg[/attachment]
[attachment=1]Appl_dwl_progress.jpg[/attachment]
[attachment=0]Appl_dwl_failed.jpg[/attachment]
Just tested it again on a clean installation of DS with a brand new serial port (Sunix SER5437 PCI express port). Same result.
@Tyrone: You seem to have exactly the same problem.
Here is one example of a timeout. I do get different ones as well.
Open and load port COM6 => ERROR: Time out: 20000ms
Open and load physical port COM6 => ERROR: Time out: 20000ms
Open port COM6 => DONE: Port opened
Open port COM6 => DONE: Port opened
Load informations from target => ERROR: Time out: 20000ms
Waiting for module detection => ERROR: Time out: 20000ms
On my side, I’ve upgraded our reference board to 7.51 and it works perfectly. This does indicate that there could be something different on our board. We use UART 1 only for serial communication to Developer Studio, and no other peripherals are connected to it.
I have been experiencing all the problems that have been mentioned already in this thread (time outs, device not responding, having to cut the power and restart everything, haven’t been able to debug yet on the device, anything you can think of).
Well, I installed the patch and not much have changed. I installed it, I restarted DS, I recompiled my application. Still… same problems.
I have DS 2.2.1, FW 7.51, Q2687.
For example, now I downloaded the application and when I hit the run button on Target Management I get
Set application state to Running and check => ERROR: Time out: 1000ms
Set application state to Running and check => ERROR: Time out: 1000ms
Set application state to Running => DONE: Success
Waiting for module detection => DONE: Target detected sn:AZ2130028706520 baudrate:115200
Switch to Development mode and check => ERROR: Time out: 1000ms
Switch to Development mode => DONE: Success
Pause : 300 milliseconds => DONE: Success
Check dev mode unlocked => ERROR: Time out: 1000ms
Switch to Development mode and check => ERROR: Time out: 1000ms
Switch to Development mode => DONE: Success
Pause : 300 milliseconds => DONE: Success
Check dev mode unlocked => ERROR: Time out: 1000ms
Switch to Development mode and check => ERROR: Time out: 1000ms
Switch to Development mode => DONE: Success
Pause : 300 milliseconds => DONE: Success
Check dev mode unlocked => ERROR: Time out: 1000ms
Also, I have a bunch of traces and they don’t print consistently. For example, I believe if I reset the device the application should restart by itself on the device and print the traces on Target Management. Right? I don’t think it ever does. It does print the traces some times exactly after I download my application. After that, once it gets unresponsive, I have to try stopping it, then restarting it, then, maybe, close and open the port… I just try randomly whatever I think might help to get it running again.
It is already REALLY frustrating dealing with DS and the connection to the board, and, from what I see, it is no only myself. Please help. Let me know if you want me to try anything on the board to give you some clue of what might be the problem.
when I tried to restart DS in the process of fixing the connection etc the process m2mstudio.exe never gets killed and keeps running (as it is shown on the Windows 7 Task manager). Even if I try to right click to end it or end the process tree nothing happens. m2mstudio.exe is there on the Task Manger, and of course if I restart DS then when it tries to connect to the COM port I get the message than the serial port is already used by another process. That other process is the previous m2mstudio.exe that doesn’t die.
So, I have to restart Windows now to fix this. I think I read this somewhere in another thread.
BTW, I thought that designing and building the hardware would be the difficult part in my project (especially that 100-pin connector). In the contrary, the hardware was a breeze!! Software… not so much… Quite the opposite actually!
I haven’t upgraded to 7.51, but on 7.47 the behaviour seems better. I do see one problem: After downloading the Open AT application, the serial number fails to refresh and the whole refresh process stops. No error dialog is shown, but a red error is displayed next to “Target Status & Configuration”. Performing a refresh again solves the problem.
I haven’t had any timeouts or failures in downloading the application or starting a debug session.
@pvouzis
Regarding the traces: Remember that the trace configuration is sent to the device. If you had a timeout, you’ll often see that the trace configuration according to DS is not in sync with the device. In the past, I’ve had to force the them to be in sync by making a few changes to the configuration.
The behaviour you’re seeing with 7.51 is exactly what we had as well. I don’t have time to upgrade to 7.51 atm, as we have a deadline for next week. I will attempt the upgrade again after that and provide feedback.
I will try to downgrade by bootloader as well to see if that will fix things. However, before doing this I want to ask if anybody has any experience downgrading their bootloader. I am asking because daav said in another post:
“Before upgrading from 7.4X to 7.5X, you shall first upgrade the bootloader to the latest version (the one packaged with 7.51 FW). Actually, this is something to do every time you want to upgrade a firmware (not for downgrade; it is not recommended to go back to former bootloader versions).”
So, I just want to make sure that downgrading the bootloader is a safe thing to do. I believe if I break the bootloader than I am pretty much even more screwed with the specific module. I don’t want to make it unusable by breaking the bootloader, because my understanding is that if that doesn’t work, then it won’t be possible to download anything on the device.
So, has anybody downgraded their bootloader successfully?
