Brick Buddy 3 Its Alive

 

Well kind of.  The light flashes (see yellow arrow) which means the main loop is working.  As you can see all of the through hole connectors need to be installed and a few other parts.  I can start testing the LED control right a way and then move on to motor control.  The only mistake so far is on the back side.  I added an I2C EEPROM for more memory storage of scripts.  This type of memory does not have the restrictions on it as does using any left over program flash for this purpose.  The clip holds the Tag-Connect ICSP connection for the PICKit.  For now I am using the on chip EEPROM.  When the time comes, I will "jury rig" something to make the connection and have the memory.

But the first day was a roller coaster.  It works then it doesn't.  And it all came down to writing internal EEPROM with the debugger attached.  This is FYI for anyone using PIC18FxxQxx processors, but might apply to K processors also.  

I added the FTDI part (did not have the assembler do any backside parts), Windows recognized the FTDI part and my Brick Controller PC APP that controls all my boards connected just fine.  I needed to do some Win APP updates for this board, so I downloaded the firmware just to reduce the variables.  This is the same base code that runs in all boards.

It downloaded just fine and started running.  I disconnected the ICSP,  unplugged the USB and reconnected and nothing.😮  No lights, no connections, just nothing.  How do you find a problem, without a debugger.  Okay, the ICSP has three wires PGC, PGD and MCLR.  Has to be MCLR or some power up config.  Checked all of that, everything looks good.

I have an LED on a PORT pin.  So I built an infinite while loop that toggles the LED, just in case I needed to look at it on a scope. Put the loop as far in the beginning of the code as I could and it works.  Now I started moving the loop further down the initialization until it failed.  It failed while writing to the EEPROM.

I have base code that gets the serial number, evaluates it and then decides if it is valid (generally fails on all 0xFF, which is a new programmed part).  If it fails, it will save a generic serial number that will validate, but that I know indicates the serial number needs updating.  Also a good test of read/write of wherever the storage is.  I have had problems in the recent past with some newer processors (non Q type) where the solution was to use the library to read/write.  But for my code for this Q processor, I just followed the data sheet example.  When I tried to use the library, the compiler said use the MCC, the library is deprecated.  I examined the MCC generated code and other than using ASM in the lock sequence, there appeared to be no difference, except.....

All of these new processors are 24 bit address for ALL memory.  I noticed the MCC code was intentionally loading all three NVMADR registers.  Where in other processors with 256 bytes of EEPROM, the upper bits really did not matter.  Well in this PIC, they do, if you are not using the debugger.  With the debugger attached, you dont need to load the upper 16 bits, but a normal production start and yes you need to correctly load those 16 bits.  Don't understand it, but that is the way it works.

Now I can get back to updating the Win APP.