-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Instability to start the application download #11
Comments
I've had that experience as well, and have assumed it was due to the ribbon cable wearing out over years of use. When I'm having trouble with the connection in Dynamic C, I'll try applying some pressure on the debug connector to ensure it's making good contact. If it can make it past the BIOS download step, it's generally successful. Once I see Dynamic C start the compilation, I know I'm good. I'm also in the habit of doing "Compile to .bin file" before compiling to target, to ensure that there aren't any syntax errors in my program. Once I've verified that, I'll try compiling to target. I wasn't aware that RFU was more reliable. I know that RFU from Dynamic C 10 had various improvements made (including batch programming with multiple cables), and it was designed to work with all board types. I'm guessing that those improvements made it into the RFU from DC 9, but strangely were never ported into the Dynamic C IDE. |
When it fails the led activity on the serial line is having the pilot bios to target then a little wait another short message to the target and a reply from the target but then activity ends with a communication error message |
Paolo, I've written up some information on the bootstrapping process that might be helpful in identifying where it's failing in the process, and perhaps figuring out why the RFU sequence seems to be more reliable. |
Paolo, is this still an open issue for you, or can I close it out? |
When building to target I am having often a failure to start the download when using DC9.62A.
It fails three out of four attempts then it works, and it keeps working until I have to powercycle the target.
The RFU utility is not having this behaviour it is always doing the download so I think there is a timing issue in DC9.62A download procedure.
The target is a custom rabbit 2000 board and I have no availability of regular rabbit 2000 sbc or modules to do a cross check of this behaviour.
The DC9.62A host pc is a win11pro i7-11850H with 32GB ram so it may be "too fast" in some of the early download steps.
The serial line is a FTDI with the default windows driver and adapter cable is an original rabbit one.
Let me know if I can provide more useful data to investigate the matter.
The text was updated successfully, but these errors were encountered: