 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 : MM: Something wrong with my CMM/UBW32
| Author | Message | ||||
Juri74 Senior Member  Joined: 06/02/2012 Location: ItalyPosts: 162 |
hello all, yesterday after doing some programming (i use a colour maximite based on ubw32 firmware version 4.3A) happened something strange: after pressing key F2 to save work, maximite rebooted.. i lost all my work since the file on my sd card was lost.. the program implied the use of a .mod module that is copied on drive A (ofcourse :D) i tested a lot and that program worked very well.. today i started the work from scratch, but every time i copy a module to the internal A drive i got this error: [11] copy "test.mod" to "A:t.mod" Error: write to flash memory failed to verify correctly moving to A: drive (with "drive a:" command) and issuing the command "files" this is displayed: 0 files, 4076 bytes free at this time, with no reason (accidentally) i writed 0 + Enter and maximite rebooted (i find that it reboot only after that error 11) another fault is when i run a program in implied run mode i get this error: Error: program in memory not saved so i have to load it with "load program.bas" even the "edit program" does not work, it give: Error: cannot find file any clues? how can i reset all to bring the A: drive memory back? anyone else has encountered this behaviour? Juri |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 6099 |
One way to get the a: drive back will be to re-flash the MM. Jim VK7JH MMedit MMBasic Help |
||||
| Juri74 Senior Member Joined: 06/02/2012 Location: ItalyPosts: 162 |
thank you, i done that and i got drive a: back alive, but i still experiencing mm reboot after a save losing all my work, this happen about 1 time every 3 saves, and it started after flashing v 4.3A (with 4.3 i hadn't no problems) |
||||
| aargee Senior Member Joined: 21/08/2008 Location: AustraliaPosts: 255 |
This is not a physical problem with the Pic32 internal flash memory? All that stuff about read/write cycles comes to mind, although that shouldn't be a problem as Geoff has pointed out in the past. - Rob. For crying out loud, all I wanted to do was flash this blasted LED. |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
It does sound that the flash endurance is reached. Only a 1000 cycles are guaranteed after that errors can occur. If you save your work to internal flash every time this endurance is reached pretty quick, but only if the files are big enough so that the same region of the flash is used every time. Small files would 'walk' through the available space and spread the wear. If little space is left or files are large the chance that the same area is used increases and those 1000 cycles are reached sooner. Are those MOD files big and changed frequently, like tens of times a day? My personal use is to save frequently on my PC and when it works on an sd or if really necessary then to the internal drive. Microblocks. Build with logic. |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2914 |
Hi Juri, Whilst you may quite conceivably have hit the magic flash cycle Number, It may also be power supply related. How are you powering your CMM? If on USB try using a commercial 110Vac(or 220Vac depending on what Mains voltage Italy uses) and as short a USB cable as possible. Also try powering off a 9-12Vdc external power source. If that doesnt work then possibly you need a new UBW32 PCB or replace the PIC chip. Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| Juri74 Senior Member Joined: 06/02/2012 Location: ItalyPosts: 162 |
ok, i miss to explain some things, sorry :P 1) i ever save my work on sd card, i use internal a: drive only for modules 2) i think internal a: drive have used less than 20 times, i use routines that check if a module is present in a: drive and if it isn't present it will be copied. i reflashed the firmware and the a: drive started again to work (tested with my game and nick's Donut dilemma.. all ok!) i noticed that if i work with files (on drive b: never tried this on drive a:) and the program exit because a error or my ctrl-c keypress to halt the program (so files opened remain open i suppose) if i save with F2 key or with save command eventually maximite reboot and i lose my work (the file i'm working on sd card with "save" command is no more readable) sometime i can recover it with a file recover program, yesterday for example file remained on sd card but it's lenght was 0 byte, i can't recover it.. i started the program in v4.3, then i upgraded to v4.3a and problems started, now i'm going to work, tomorrow i make some test reflashing back to v4.3 to see what happen @Mick i use an external 220v to 12v 2A power source, ever worked very well, i tried also with a 220v to 5v 1A never had problems too (exept for the RTC that is not working in 5v mode) Juri |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2914 |
Hi Juri, I would be interested in how you go flashing back to 4.3 Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| Juri74 Senior Member Joined: 06/02/2012 Location: ItalyPosts: 162 |
Hello Mick i used as usual "universal bootloader v1.1" then i flashed the file ColourMM_MMBasic_V4.3.hex, i mantain a copy of old firmwares.. just in case :) i rolled back to v4.3 with success, now i'm testing a bit Juri |
||||
| Juri74 Senior Member Joined: 06/02/2012 Location: ItalyPosts: 162 |
i finally finished a little program that i couldn't finish in version 4.3a (i will open a new thread for that) i noticed that v4.3 is more stable (for me) than v4.3a regarding save & copy operations. i found another buga XD this is in v4.3 and v4.3a too it's hard to explain so i typed a very little program to show it: bug.bas
a$="Test" Do b=Int(Rnd(1)*8) f=Int(Rnd(1)*8) b$=CLR$(f,b)+a$ If Len(b$)>6 Then Print b$ Loop i know that command CLR$() return 2 chars, so variable b$ should contain always 6 chars (2 chars color code + text "Test") Juri |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6099 |
I can confirm your bug but offer no solution. The error occcurs at random times. It happened after 24 good 'prints' and other times after 180+ good 'prints' Most of the time, the string is the same: 01 44 01 3C 01 40 01 00 00 00 1C 43 01 62 00 00 01 00 00 00 01 00 00 00 00 00 00 00 00 38 01 44 01 02 00 54 65 73 74 I did capture one that was different (72 characters instead of 60): 01 02 01 01 00 01 66 00 2C 00 62 00 00 00 00 00 00 02 00 00 00 00 00 00 00 3D 00 00 00 00 00 5F 00 00 00 2E 00 00 00 4C 05 00 05 00 00 00 41 00 00 00 00 54 65 73 74 MMBasic V4.3a on a UBW32 using the USB serial interface. Jim VK7JH MMedit MMBasic Help |
||||
CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1425 |
That is really odd. Even not using rnd will cause this to happen. a$="Test" Do b$=CLR$(0,6)+a$ If Len(b$)>6 Then Print b$ Loop Micromites and Maximites! - Beginning Maximite |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3194 |
Thanks, I can see the bug in the code but I will not be able to fix it until later in the month. Without getting too technical the string returned by CLR$() is not held in a safe memory location and other parts of the interpreter may or may not use that part of memory before the string is used. It should be work OK inside a PRINT command but otherwise the effect will be random. Geoff Geoff Graham - http://geoffg.net |
||||
| Juri74 Senior Member Joined: 06/02/2012 Location: ItalyPosts: 162 |
Hello Jim, all i could offer a solution of the problem, a workaround until this little bug will be fixed: simply replace the line "b$=CLR$(f,b)+a$" with: b$=Chr$(128+f)+Chr$(192+b)+a$
Juri |
||||
 Print this page |
