 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 : Colour Maximite programming problems...
  Page 3 of 4   |
|||||
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9082 |
I'm still having reasonably major issues with this UBW32 concept. Now, not only can I not get into the bootloader, but known stable code keeps crashing the PIC32 and causing a reboot. Example: - Take known good code and put on SD card. - Put card into UBW32-based Maximite, run code. - Code runs correctly for four seconds, then the PIC32 auto-reboots. Now, take exactly the same code, on exactly the same SD card, pop that into a CG CMM2 board, fire up and run the same code again, and it runs flawlessly. ...I also can put the CG unit into bootloader whenever I like. PLEASE NOTE AT THIS POINT: BOTH my UBW32 and the CG CMM2 are running the exact same version of MMBASIC, that being 4.4 Is it conceivable that I have a crook UBW32? I have a couple of extra UBW32's - I will take another one, and plug it into this board and see if the same problems presents itself. Is it possible to have a functioning PIC32, that for all intents and purposes APPEARS to be fine, but is in fact, crook? Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9082 |
OK, new UBW32 fitted, and this one seems to be working much better. THIS module, I could program from IPE without issues(no need to set config bits or use IDE to program), using the 4.0 with bootloader HEX file, and importantly, I can get into bootloader as you should be able to, by shorting C13 to ground then powering up. I was able to update to 4.4 using the bootloader and USB, so that is all working now. Even though BOTH versions were 4.4, on the 1st UBW32 module, the code would just reset without saying anything, back to the startup screen. Now with the 2nd module, I am still getting the reset, but now it is telling me it is because of a watchdog timeout, which it was not doing on the 1st module. Fecking odd, eh?  
Still no idea why the exact same code will run OK on the CMM2, but not on my board, but the only thing that is electronically different between the two is that my board uses the DS3232 RTC instead of the 1307. I update the date/time on the screen every 250ms - perhaps the 3232 does not like that. The 1307 obviously has no issue..... Smoke makes things work. When the smoke gets out, it stops! |
||||
| WhiteWizzard Guru  Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
My first thoughts are power stability. Are you using the same PSU for both? If not, then try the CGMM2 supply with the UBW. If you are using the same PSU then check the caps - specifically the 10uF/47uF cap. These can cause the issues you are seeing. Is it a specific line of code causing the reset? If you rem out chunks, can you prevent the reset? The fact you can't get into the boot loader does seem strange - I assume you mean not on the UBW but you can on the CMM - correct? Awaiting your answers before I can suggest anything else . . . . WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9082 |
I can get into the bootloader on the UBW32, and I can program it with MMBASIC without having to change any of the config bits - using IPE. That is with the 2nd UBW32 module. The first UBW32 module, I could not get MMBASIC to start without playing around with config bits in IDE, and also the bootloader refused to work on the 1st module. That module is now in the bin - I suspect it, and it is not worth keeping it around as it seems to me, to be a bit fluffy. This 2nd UBW32 module, I could program fine in IPE without touching the config bits in IDE, and it runs MMBASIC as it should. This 2nd module also allows me into the bootloader no problems too. The issue now seems to be with the RTC. This is still and odd one, cos even if I disable ALL the watchdog commands, and by that I mean use MMEDIT to find all WATCHDOG commands, and remove them, then check again to make sure they are all gone, download that code to the MM and run it, I still am getting the message about the watchdog timer resetting the MCU. Now, that is impossible if there no longer exists any watchdog commands with which MMBASIC can time-out on, so about the only other thing I can think of that COULD cause this kind of behaviour, is if MMBASIC crashed somehow in a rather fatal fashion, causing a core exception which would restart the PIC32 core. I'm open to other suggestions at this point, but the fact that the very same code, on the very same SD card, in the very same folder - crashes after 4 seconds on my UBW32 board, but runs fine on a CG CMM2. ...really odd... All I can think of, is that it is the RTC chip. Bear in mind, that the Maximite RTC was designed around a 1307, and therefore, there may be some obscure problem with substituting a 3232 in it's place. That's all I can think of at the moment. Smoke makes things work. When the smoke gets out, it stops! |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
Is it easy for you to drop in a 1307 in place of the 3232 to eliminate that? For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9082 |
Heh, heh - great minds think alike! 
I will do a PCB hack to establish if that is the cause tomorrow. I have a couple of 1307's in DIL, but I can just run jumper wires to the correct pads(having removed the 3232, naturally), and we'll see. My code calls the RTC every 250mS. I tried altering this to 500mS and 1000mS, but I get the same 4-second death throws..... This just does not happen with the 1307. The 3232 can operate as either 100kHz or 400kHz, whereas the 1307 is 100kHz only, so I am wondering if the 3232 is getting confused or something around bus speed, which locks MMBASIC and causes a MIPS-level processor exception - the PIC32 restarts itself, and MMBASIC detects this as a watchdog timeout when it isn't, due to the abnormal restart. All guesses though. I will do a RTC swap tomorrow, run the code and see what happens. Smoke makes things work. When the smoke gets out, it stops! |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2870 |
Grogs, Two things.. First your mention of `config bits' has perked my mind... I remember chasing my tail and not being able to flash a MM or CMM (UBW) with the default Config bits.. I had to change one or two... From memory it had something to do with XT clock (there were 4 settings I had to change to something else and override the default settings) Secondly I had a UBW32 which `played up' and I had to parallel another 10uF cap across the existing VCap.. Hence why I still, even on the uMite, use a more costly 47uF tantalum even though every one else says they use a 10uF ceramic with no probs. Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2870 |
Grogster, Try what Zougie did in this TBS Thread TBS Thread Regards, Mick EDIT **** My Post on the next page has what might be the answer you need. Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9082 |
UPDATE: I removed the 3232 and just fired up without an RTC at all, but I am still getting watchdog restarts with no watchdog commands in the code. Wierd..... I'm stumpted. What I can say, is that it works fine on the CG CMM2, and also the Altronics kit too(I had one of them in a drawer, so I dug that out). With no RTC at all, that should have ruled out the 3232 locking up the PIC32 in any way, it would just mean that you would lose the clock settings every time you power off. I don't understand how the code will work fine on the CG CMM2 or the Altronics kit, but not on my board. Suggests that I have made some kind of error on the layout. I see nothing obvious, but I will now triple-check my layout for errors. Probably easier to just build around the CG CMM2 board - which is what I was going to do in the first place - I should have stayed on that path. Smoke makes things work. When the smoke gets out, it stops! |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
Is it worth now reloading the firmware (and with the RTC still removed) see if you still get the same problem. Also - what message are you getting on the screen to indicate a reboot (I assume its just the standard 'Welcome' message being an earlier firmware? You mention 'my board' and 'on the layout' - are you sure its not a capacitor issue? Or a PSU issue not delivering enough current? WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9082 |
No. I get the: "The Watchdog command timed out and restarted the processor." type message - with no Watchdog commands in the code. That is the bit I can't fathom. Yet the EXACT same code, on the same SD card, in the same folder, runs perfectly on the CG CMM2 or the Altronics kit. Anything is possible at this point re the cap(s). PSU is 7809 feeding the UBW32 with plenty of decoupling, and main supply capable of 15v @ 1A, so I don't think there is a lack of current or regulation issue, it seems to be something else. I am now looking into designing a mother-board for the CG CMM2 - at least I know that one works right out of the box. "A man's got his patience, and here's where mine ends." Name that reference. 
Smoke makes things work. When the smoke gets out, it stops! |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
Grogs - do you want to send me the code and I try it on some MaxiMites here (but I haven't got a UBW32 variant). Which firmware are you currently trying this with (I know you have mentioned earlier in the thread BUT you may be trying other ones now - so let me know the latest version that exhibits this issue and I will try to 're-create' here. WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
Grogster, You said that you used MMEdit to remove all WATCHDOG commands. Can you be sure that you have updated the correct program on the UBW? I have been caught before when a reboot runs AUTORUN.BAS and not the program that I had just saved. Jim VK7JH MMedit MMBasic Help |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9082 |
@ WW - Version 4.4 on both the UBW32 and CG-CMM2 and also on the Altronics unit. I wanted them to all have the exact same version, so I could rule out version numbers causing any issue. As for the code, if you don't have a UBW32 based maximite, sending the code would be kinda pointless me thinks, cos the code works fine on the other maximite clones - everything would work for you perfectly for the same reasons. @ Jim - Yes, copied the code as a different filename, and autorun.bas is not on the MM, so when you fire it up, it just stops at the welcome screen. I manually run the code. HERE is a link to the mainboard I designed for the UBW32. WARNING! - This is a big image - 2.8MB in size. I made it huge, so you can zoom in and out of the image to examine all the layout. I don't THINK I have done anything silly here, but you never know, so I would appreciate other peoples eyes in that department. Ignore any layout preferences etc(read: how you would route things), just concentrate on spotting any electrical errors please. Smoke makes things work. When the smoke gets out, it stops! |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
I don't see any obvious error on the board layout. I do have a UBW32 to test the code on if you wish. Jim. VK7JH MMedit MMBasic Help |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9082 |
OK, I have gone back ten versions of the code, but the code still crashes on the UBW32, but not on the CG or Altronics units right up to the current version of the code. I am not convinced that the UBW32 is 100% MM compatible. Why else would all these problems surface, but not on the CG or Altronics units? Is it conceivable that having the UBW32 elevated up in the air a little from the board as it plugs into the header strips, could possibly be causing a sheilding issue or some other thing like that? I have even tried copying the code to a fresh SD card thinking that perhaps the card I was using was suspect or had started to become flakey, but nope - exact same self-resetting problems. I COULD split the large code up into modules and use CHAIN to hop between them, but so long as there is enough memory to run the code, I don't think this should be a requirement for a code that otherwise runs fine on other platforms - and I don't want to go to that trouble unless I know it would be worth the effort to do it. MOST strange.  I will be in touch via PM with both Jim and WW to get them to try the code. Especially interested in Jim's test, as he has a UBW32 MM, and WW does not.
Schematic for UBW32 shows that U2 and U3 are 1117's, and a reverse-blocking diode(D1) has 0.5v drop. Consulting the 1117 datasheet, the dropout voltage is 1.1v meaning that I need at least 6.2 volts input. I am feeding 9v in, so I am convinced that the supply voltage is sufficient. I have also tried running the UBW32 from USB power by flicking the little PCB switch to USB, so that I can remove my 9v supply from the equation, just in case there was noise or SOMETHING wrong with my supply voltage. Guess what? On USB power, it still dies in exactly the same way. It's one of those really obscure problems: It should work, but does not. 
Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9082 |
UPDATE: There appears to be a slight code-vs-electronics bug going on. I have tracked the problem to COM2's input buffer overflowing. When the COM2 RXD buffer contains more then one byte, an interrupt designed to monitor that, sucks the bytes from the buffer into a string via a loop. When the buffer contains more then 250 bytes, the code forces a restart with WATCHDOG 1 to clear the buffer and allow the system to auto-recover. The input buffer of COM2 should never get that full by design, so this is a preventative measure(to stop the system locking up with a queue of messages it can't clear, or falling over to the command prompt with string length errors). I have a 10k pull-up on the PCB with a box around it(just below the RTC battery), that is only supposed to be installed for the early version of the receiver which did not have a pull-up. This resistor ties the RXD input pin high to prevent this floating issue, and I remember having that problem in prototyping - hence the optional resistor. I have not installed this, so if COM2 gets some noise on it's RXD - which will happen with the high impedance of the pin when left floating - the buffer fills up to overflowing with garbage bytes, and the system restarts to recover. I have confirmed this by removing that watchdog command, and replacing it with PRINT "Buffer overflow." followed by END, to stop the auto-restarts. I think if I fit this resistor I am hopeful my problems will go away - I will do this now, and post back. ...still does not explain why code works fine on CG or Altronics units, which also have COM2 RXD floating... The saga continues. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9082 |
OK, everything seems to be running as expected now, so I think I have tracked down the problem. Moral of the story: Beware the high-impedance input!
I will now re-install the 3232 RTC, and hopefully everything will be working like it should be. Smoke makes things work. When the smoke gets out, it stops! |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
[laughing considerably] i worked on a project a while back that had this exact same problem. with certain configurations of hardware on an earthmoving machine, an installed winCE box would run incredibly slowly. it turned out to be an unterminated serial port input line that was causing 'interrupt storms' consisting of 10's of thousands of interrupts happening every second. we fixed it with a firmware change. the complete systems sold to customers for $100k or thereabouts per machine. it is likely that some unrelated feature of your board/wiring layout is allowing the issue to happen. it could even be caused by the type of PCB material used. but if the serial port has not been configured with MMbasic code, it does illuminate a serious bug that needs to be addressed. geoff: are you reading this thread? i would expect that (a) unconfigured serial port hardware would be kept completely shut down, and (b) that when a serial port is configured all associated input pins would have light pull-ups turned on to prevent the inputs floating between 0/1. rob :-) |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9082 |
Rob, I'm glad I made you laugh! - I am guessing you are not the only one..... 
Everything fine now for about 15 minutes, and no matter what I try, the system is rock solid now, which is how it should be - I perfected the code as much as possible BEFORE I designed the mainboard around the UBW32 module, in the thought that I might have to fine-tune, but everything should work right away. "Oh surely you're not THAT naive?!(rhetorical)" I remember seeing this issue(string length overflow errors) when writing the code, and to fix it, I added that 10k pull-up to 5v on the breadboard prototype, but as I am now bench-testing the PCB prototype - and I DON'T have the receiver connected, there was never any pull-up, either via the mainboard, or via the receiver itself, so COM2's RXD line was floating, and cos I am checking that all the time with the likes of "If LOC(#2)<>0 Then...", as soon as MMBASIC thinks it has a byte in the buffer, without the pull-up, the buffer fills up to 255 bytes of gunk, and the system restarts by design. ...seemed like a good idea at the time - detecting that and forcing a reboot!!!!! 
Smoke makes things work. When the smoke gets out, it stops! |
||||
| Page 3 of 4 |
|||||
 Print this page |
