 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Picomite dropping bytes on autosave
  Page 2 of 2 |
|||||
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
230k4 baud seems a bit fast to me. I know you said it was working fine, but it might have been right on the edge of what it could handle if you see what I am getting at. I would not be inclined to try to run the console faster then 115k2, which is the default setting. The manual suggests that the PM does not care about the baud rate, and it will ignore any setting there, but there would HAVE to be a limit somewhere, and 230k4 is pretty fast! I'd set the console back to the default of 115k2(OPTION BAUDRATE 115200 command on the PM module, and reset your terminal speed to match), and see if that fixes it. If it didn't, I would slow it down even further to the default speed of 38k4 which all the other MicroMite series of chips use as the default console speed. The delay mentioned in posts above should also fix, but if not, I would just throttle back a bit.  Smoke makes things work. When the smoke gets out, it stops! |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 6099 |
Apart from 1200 baud which puts the pico into firmware update mode, the baud rate has NO effect. OPTION BAUDRATE only changes the serial console on a com port rather than the USB. When your terminal program sets the pico USB baudrate, the pico says "yes sir!" and then ignores the request. The only way to slow the data down is with character delays or a line delay. Pasting a line at a time is the poor-mans line delay. If you are lucky, your terminal program does scripting. That should allow a slow paste. TeraTerm has that ability but it also has the required line delay setting. Jim VK7JH MMedit MMBasic Help |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
 (from: https://www.mac-usb-serial.com/docs/tutorials/access-serial-port-on-mac-with-coolterm.html) can you confirm that NONE of the flow control check-boxes are ticked, and that "DTR On" and "RTS On" are both selected? cheers, rob :-) |
||||
| jovian Regular Member  Joined: 16/04/2017 Location: AustraliaPosts: 62 |
I use the inbuilt visual basic extension - works really well! Functionally perfect, only thing I've noticed is that if you type EndIf as one word, it colours it incorrectly. I use 'end if ' so that the colours are all correct, and MMbasic doesn't object, it simply recompiles it as EndIf on the way in. Everything else about it is brilliant |
||||
| jovian Regular Member Joined: 16/04/2017 Location: AustraliaPosts: 62 |
Yes, only diff is I have baud at 230400. It's working perfectly now I have put the temperamental Pico aside. Thanks Joe |
||||
| jovian Regular Member Joined: 16/04/2017 Location: AustraliaPosts: 62 |
Thanks Grogster Well, I disagree, I do not get spurious errors at all and never have. My softwares get long and the advantage of uploading them twice as fast is hard to argue with. Because I am making every small adjustment in VSC and pasting across each time. The weird bit that I do not understand is that with the errant Pico, the identical bytes would drop out, regardless of baud rate. Right down to 9600. If I went back to the source code, located the dropping-out bytes, and typed in another one next door, (eg Print ""Hello"), it would actually compile properly! At least up to the next dropped byte, which I could then repair the same way. Every time, regardless of baud. If I put an extra character at the start of the program (the ' symbol), the places where the dropped bytes happened would shift to a new location. But not one byte along as you might expect, somewhere a few lines down the track. But then reliably and repeatably stay there as well. It is an interesting fault and as I said I have had it once or twice before on 2 or 3 out of about 90 picos I've burnt but this time I wasted half a day trying to get to the bottom of it, and was curious if anyone else experienced it and knew the fix, if there is one. |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 865 |
Apologies for the dumb question but you do have Rx, Tx and Gnd from your comms adapter, right? |
||||
| jovian Regular Member Joined: 16/04/2017 Location: AustraliaPosts: 62 |
Yes, I believe these are symptoms of logic cutting sick. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
OK, thanks for that Jim - I stand corrected.  Smoke makes things work. When the smoke gets out, it stops! |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
since everything else has been covered, it feels like the problem you and others have seen may be an aging flash chip on the pico. i say 'aging' and NOT 'failing' as it could well be that as the flash chip ages it takes longer for a block erase operation (128-byte blocks) to complete - this may be perfectly normal. however, during this (very brief) pause, the pico could somehow be missing the odd character being sent from the host - some terminal emulators will block together groups of characters, while others will send them individually. similarly, different operating systems will employ different strategies here. it could also represent a small bug in tinyurl that has gone unnoticed. i also believe that, on the pico, mmbasic makes use of ROM routines to write to flash, and there may be a bug down in there. peter would be far better equipped to comment on this. when the 'error' location shifts, how many characters does it shift by? a good experiment would be to use repeated data statements, for example: data "1234567890abcdefghijklmnopqrstuvwxyz" or comments: '1234567890abcdefghijklmnopqrstuvwxyz as data and comments are not tokenized, you'll get a better feel of how far apart in flash errors occur. cheers, rob :-) Edited 2023-11-11 13:47 by robert.rozee |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2135 |
This may be random rubbish but... In the print "hello " example on the previous page there are 16 lines of 16 characters (counting <CRLF> as two) between errors.Edit Correction, on a recount it's 16 + 2 half lines but changing <CRLF> to <CR>** brings the total to about 255 characters between errors. If the receive buffer is 256... ** I guess it depends on what the terminal emulator is set to use. In TeraTerm the default is <CR>. Edited 2023-11-11 17:03 by phil99 |
||||
| jovian Regular Member Joined: 16/04/2017 Location: AustraliaPosts: 62 |
The worn out Pico theory is a distinct possibility. The Pico I started on had already been used for some developing 18 months back. As I do my work in VSC I am pasting back and forth the full program a lot. The last program was thousands of lines long so there is a chance I was flashing this pico hard. Grogster's comment about the xfer baud being high at 200k could have relevance in so far as it possibly wears the flash harder? One things for sure the error is consistent so someone who knows the architecture may be able to pinpoint the cause. Perhaps the takeaway is to be mindful of over flashing the thing.... Repeated data experiment below. This is text pasted from the clipboard to the errant Pico. Then copied off the terminal and into the forum page. Dropouts can be observed. I get an identical result sending at 38400 and 230400. All Pico settings are default. autosave 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 012345689abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 012345679abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 012345678abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789bcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef |
||||
| jovian Regular Member Joined: 16/04/2017 Location: AustraliaPosts: 62 |
SOLUTION  Use packet delay: 1mS , Transmit Packet Sacket Size: 128 Grogster mentioned character delay and I'm sorry I didn't try it earlier because it fixed it straight away, despite longer transfer time (I mistakenly presumed character delay would create the same outcome as lowering the baud). RR mentioned a brief pause after a 128 byte block erase - and setting the packet delay parameter to 128bytes with a 1mS delay has in fact... drum roll please... solved it! Too late for my Pico which has been brutally retired from this project but very good to know there is a tangible cause and workable solution. Thanks all  J Edited 2023-11-12 10:44 by jovian |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 865 |
"brutally retired"  Reporting you to the MCU cruelty authorities |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
congratulations on finding a solution someone should report this to peter and geoff - if it is a common problem (or one that may eventually afflict many pico's) they may need to look into finding a firmware solution. there may be value in collecting together pico's exhibiting this behavior for further analysis. it just occurred to me - the MX170 version of mmbasic buffers to RAM during AUTOSAVE. does the pico version not do the same? cheers, rob :-) |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6099 |
A packet delay is roughly equivalent to a line delay and that requirement has been mentioned in many places many times. Jim VK7JH MMedit MMBasic Help |
||||
| jovian Regular Member Joined: 16/04/2017 Location: AustraliaPosts: 62 |
I'm sorry Jim, I feel like I've been wasting your times. I'm a dunce when it comes to how chips communicate at the terminal level. But in this instance I can demonstrate that I have stumbled upon a difference between packet delays and line delays, because tweaking the line delay parameter doesn't resolve the error. Even switching packet delay in at 256 doesn't affect it. Packet delay at 128 is the magic bullet. So even if they are roughly equivalent, it ain't enough. Took me a while to get there, but I hope this info is useful to someone and I appreciate all of your help. |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6099 |
My mistake, I though from your earlier comments that you can't set a line delay in your terminal program. It is good that you have found a solution. Jim VK7JH MMedit MMBasic Help |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
Not a waste of time as far as I am concerned. This thread was very interesting, and it is useful information to know, should it happen to anyone else, so please don't worry or think you were wasting the forum's time or any of the members. We're all a pretty happy bunch here, so no-one is going to get nasty. The handful of newbies that HAVE come here and tried to rule the roost, get kicked out of the henhouse pretty quickly by either me or Glenn(forum owner). Smoke makes things work. When the smoke gets out, it stops! |
||||
| Page 2 of 2 |
|||||
 Print this page |
