Firmware development

[ian]

Sorry, here's the source.

[colin.i]

How far does the firmware run?  Do you have an LED set up to blink or anything like that?  Have you messed with the config bits?  Why do you have the config USBDIV commented -- is it due to the PLL startup or something?  Have you tried using a snooper on the USB lines?

Its sort of hard to debug if I don't know where you stand on this :)  Unfortunately I don't have any spare 18F24J50s lying around :)

[ian]

Yes, I replaced the config bits with a working set from my CDC firmware for the J chip.

USBDIV is not a config option on the 18f24J50 PICs. It is fixed /2.

I don't have a snooper for the USB lines, and there's nothing going on in Windows to snoop at the OS level.

The firmware runs as expected, the USB configuration setup is correct and the USB pullup resistors are enabled, the OS sees the pull-up and detects a USB device insertion, but from there nothing happens. During debug it hits the sleep instruction around line 253 of boot.asm a lot, but seems to wake up on interrupt every time. It's hard to tell with debug because it slows it down so much that it also causes unknown device errors.

Since the USB peripheral is nearly the same, except the banking required to reach the registers, I assume it's another architectural difference I'm not getting. I've confirmed that there's no special J part defines in the CDC firmware, so I'm strongly inclined to believe it's some ASM that's incorrect for the 18xxjxx chips.

[colin.i]

Okay I'll start looking through the ASM specifically now.  Out of curiosity, have you tried SnoopyPro for the USB?  It goes down fairly low level, not sure if it can read activity without a VID and PID pair but since I don't have hardware I can't test it myself.

[ian]

Yes, that's the program I use. I couldn't get it to show anything at the enumeration state it got to (no VID/PID as you say, just !SE0)

[colin.i]

When I run the simulations, everything seems to be fine.  Obviously I can't test with an actual USB request being sent unless you know how to emulate that in MPLAB.  Ive checked over the config bits briefly (I assume they work since you've used them before) and I went through instruction by instruction, watching the SFR values.  Everything seems to be fine as far as your initialization goes...

I'm a little tight on time for today, but later on I'll try to fake a packet or something and see how the firmware responds.  Let me know if you make any progress!

[jack.gassett]

Checked into svn is a new VHDL project to generate signals for testing the Sump Pump board. This testing core can be loaded on a second Sump Pump board and the two can be connected with a ribbon cable. The code is checked into svn here. A 100Mhz signal is generated on channel 0 of the outside row numbering scheme. The frequency is cut in half for every channel after that.

The initial results from testing with my two prototype boards is located on my wiki page. There were so many pictures that it was not practical to post them all here.
Initial Results in the Project Wiki

The results are that it looks like the 200Mhz sampling frequency is able to capture the 100Mhz signal on both the buffered and unbuffered pins. The unbuffered pins seem to have less noise and glitches than the buffered pins.

[Bert]

It looks great! So... when can I buy one?

[goldserve]

I'd like to buy one too!

[ian]

Ha! Got the bootloader to enumerate as USB HID. I think it was the register problem, but then I only ran it under debug, never as a complete app, so the timing was messed up. A last desperate attempt to get it to work, and bang, it worked!

I'll get it reading and writing tomorrow. Then some stress testing of the firmware to go with Jack's testing of the FPGA, write an article, and we're ready!

[RichF]

The results are that it looks like the 200Mhz sampling frequency is able to capture the 100Mhz signal on both the buffered and unbuffered pins. The unbuffered pins seem to have less noise and glitches than the buffered pins.

Jack:
Would it be posible to check with serial termination resistors, to see if that would clear the glitches?

[ian]

The bootloader seems to be working well. I've updated it with a bit of extra protection to guard against erasing the bootloader or config bits.

Another snag I hit is that the 24j50 erases 1024byte pages instead of the 2550 64bytes, and the 24j50 writes 64bytes at a time instead of 32bytes. This is going to require some updating of the bootloader app.

The app is VC++, I've downloaded the free express edition and I'm installing the driver pack for HID now. I'm going to take a stab at compiling it, and then updating it. If there are any VC++ developers listening, I might need your help before this is all over.

As a precaution, I also got the Microchip bootloader working. It's not redistributable, and the app is only windows/.net, so it leaves a lot to be desired. If I can't get the Diolan bootloader working, this is ready to go. We can't get the PUMP produced before the Chinese holiday over the next two weeks, so there's no major rush.

[ian]

Wow, well that was quick. I got the windows driver development kit so I'd have the required .h files to use USB HID, but I get hundreds of errors. I'm not a PC developer, so while I can modify the code to work with the diolan bootloader, there's really no way I'm going to get this updated if there's lots of things to be fixed. I guess I'm going to give up on the diolan bootloader and use the Microchip bootloader instead. Too bad.

[robots]

Can you give me the link to the VC++ project ? I'll give it a try. Windows is not my primary development platform. But if you use the right hammer ... :))

[robots]

I can now compile the fw_update. :)

I can either tell you how to setup the environment or i can compile patched file for you. Can you drop me an email ? so i don't have to poll for reply