Spin compiler download timeouts!
Peter Jakacki
Posts: 10,193
Here is the problem:
A large program that compiles with 6260 longs fails to load with the infamous "Propeller chip lost on COMx" message. There is nothing wrong with the pcb or power-supply etc. I have rebooted the PC, tried another PC, tried earlier versions of the Propeller IDE, cleaned the board, heated the board, cooled the board, fed external power to it etc etc.
For the programming cable I am using a CP2102 to RS-232 then back TTL. This was working fine with smaller programs. I tried downloading the same large program onto a different model that has a FT232R onboard and that loads fine.
I was able to reduce the compiled code size from the source to find out at what approximate point it would work or not work.
Downloaded different sized variants of the large program and this is what happened:
5924 longs will load
5940 longs will load
5956 longs will fail
So I decided to hookup the analyzer to the port pins to see what was happening.
D3 RXD in
D2 TXD out
D1 SDA
D0 SCL
As you can see from the loadram_ok the IDE download the complete image then polled 3 times for an acknowledgment before verifying and rebooting.
But look what happened when it failed. The IDE spits out only a very short burst of data and then polls for an acknowledgment ~15 times before timing out. When you look at the I2C bus you can see why because the Propeller is booting. Just to make sure it wasn't a reset glitch I hooked another probe to the reset line (not shown in attachments) and you could see the programming reset pulse ok and there certainly wasn't anything else to cause it to do that. The same goes for the power supply, no problems.
I'm still investigating but I thought I'd share this little bit of information hoping that maybe someone would have some new ideas based upon the evidence (other than all the ones we have heard of previously).
My thinking is that the load is going in reverse order and the top of memory is getting clobbered first. Although I haven't checked it seems some boot code or variables are living there. But that doesn't explain the FT232R version working fine. It seems then that the issue might lie with the Windows VCP and the IDE's timing. Of course, anything to do with Windows (I'm using XPSP3) invites trouble.
*Peter*
P.S. I have added a photo of the board under test.
Post Edited (Peter Jakacki) : 2/21/2009 6:20:19 AM GMT
A large program that compiles with 6260 longs fails to load with the infamous "Propeller chip lost on COMx" message. There is nothing wrong with the pcb or power-supply etc. I have rebooted the PC, tried another PC, tried earlier versions of the Propeller IDE, cleaned the board, heated the board, cooled the board, fed external power to it etc etc.
For the programming cable I am using a CP2102 to RS-232 then back TTL. This was working fine with smaller programs. I tried downloading the same large program onto a different model that has a FT232R onboard and that loads fine.
I was able to reduce the compiled code size from the source to find out at what approximate point it would work or not work.
Downloaded different sized variants of the large program and this is what happened:
5924 longs will load
5940 longs will load
5956 longs will fail
So I decided to hookup the analyzer to the port pins to see what was happening.
D3 RXD in
D2 TXD out
D1 SDA
D0 SCL
As you can see from the loadram_ok the IDE download the complete image then polled 3 times for an acknowledgment before verifying and rebooting.
But look what happened when it failed. The IDE spits out only a very short burst of data and then polls for an acknowledgment ~15 times before timing out. When you look at the I2C bus you can see why because the Propeller is booting. Just to make sure it wasn't a reset glitch I hooked another probe to the reset line (not shown in attachments) and you could see the programming reset pulse ok and there certainly wasn't anything else to cause it to do that. The same goes for the power supply, no problems.
I'm still investigating but I thought I'd share this little bit of information hoping that maybe someone would have some new ideas based upon the evidence (other than all the ones we have heard of previously).
My thinking is that the load is going in reverse order and the top of memory is getting clobbered first. Although I haven't checked it seems some boot code or variables are living there. But that doesn't explain the FT232R version working fine. It seems then that the issue might lie with the Windows VCP and the IDE's timing. Of course, anything to do with Windows (I'm using XPSP3) invites trouble.
*Peter*
P.S. I have added a photo of the board under test.
Post Edited (Peter Jakacki) : 2/21/2009 6:20:19 AM GMT
Comments
"Peculiar" is a kind word.
Thanks for the reply Mike.
*Peter*
It is most certainly not that. The booter runs completely from the COG with no reference to HUB ram while running.
The "handshake" at the start of a load is reasonably timing critical. I assume the handshake is occurring properly otherwise it would be informing you it can't find the propeller. After the handshake the load must start within about 50-70ms (supposed to be 100ms but I could never seem to get it to wait that long) at most or the propeller will timeout and continue booting from eeprom. Likewise, any delays in sending the data to the propeller may cause the load to timeout and boot from eeprom. Perhaps there is a timing issue with the serial device you are using that does not exist with the FTDI stuff or a strange interaction with your particular installation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
*Peter*
Does anyone know if Parallax is looking into this seriously?
Jonathan