keithI’ve been horrible about the project lately. Dunno why.
Today is the first time I’ve looked at it in quite some time. The last couple hours have been spent trying to remember exactly where I’ve been, what I’ve done, etc.
I updated tortoiseSVN and subversion for version control. I also completely recreated the repository, reimported stuff, etc.
I’m getting good data from the PC drive, looks GREAT on the scope. Pretty happy just to be seeing something at this point.
I want to add some rudimentary power on self tests, but I’m not sure how much I can do. I want to at least do a memory check, and if it fails, to turn on an LED.
I do have a serial LCD I want to eventually bring into the mixture, I’m just not sure if I want the associated complications with it. It would be very nice for the thing to communicate back to me in some fashion. Not to mention it’d be nice for spitting out variables, error codes, etc etc.
darn Sleeping bug has crept up again.
I posted my code on the Parallax forums with the hope that someone there can identify what Im doing wrong
Could you post the link to Parallax forums here, too?
https://forums.parallax.com/forums/default.aspx?f=7&m=156073
is the link.
But you won’t find more than my description of the problem and the associated code.
Honestly, I don’t think there’s anyone who has a handle on what conditions have to exist for the microcontroller to SLEEP. I’ve posted a couple times specifically asking for more detailed info, common mistakes that cause the problem, etc and have got literally nothing useful back. Initially, people said there was nothing they could do without looking at the code. So I posted the code, and this time, I get ignored.
Now my code is an admittedly ugly mixture of SX/B and ASM, but there’s no reason that this mixture should cause a problem, as far as I know. The SX/B gets compiled to assembly ANYWAYS, and so simply loading the program, and pressing ctrl-L in SX/key software displays the raw assembly.
My current idea is to get everything to 100% assembly. I’m going to do some reading and get boned up on SX assembly, although I’m ok at it now. The ISR, USB, and FRAM routines are pure assembly right now. So really, the only thing that isn’t is program initialization, and the main program loop(ie command mode etc)
This sleeping bug is pretty elusive. I don’t know why it happens — but its not a logic bug perse. The microcontroller actually stops executing instructions. How come? Program counter doesn’t point to a valid instruction? Instruction is corrupted? Not enough memory? not enough program space for the debugger routines? Nobody can tell me.
my receive uart code isn’t perfect. It generally reads stuff ok, but makes mistakes sometimes. My sending uart code is pretty good, so I’m going to keep echoing characters until I get stuff perfect.
Ok. receive uart working much better. It seems I must have had too much time between bits. I shortened it up by a cycle or so and now receiving works very well.
send routines look strong but I still think I’m going to add a weak checksum to data that’s sent.
Sleeping bug has seemed to disappear. got me. Gonna keep pluggin away.
welp. Im getting junk data again out of the drive. I really wish I could nail this down. In the past I swear these types of issues were termination issues, but I’ve checked my resistor, etc, everything is ok.
Drive is responding to the motor on and being selected. This is good I guess, but I’m getting garbage……
What’s odd is that when I started this back up again recently, I checked the data from the drive and it looked great, no problems. SO I dunno how I reintroduced the problem into the system.
I’m not making any progress at 1:47am, so its time to go to bed.