open-usb-can-rev2.sch: HW and FW mismatch?

[iDoka]

Hello
Fabio!

I want to use frash version of HW-design, but I see some mismatches between HW and FW:

1. FW does not have a handler for LED_C functionality (probably POWER_ON?)
2. FW doesnt handle INT-signal from MCP2515 (INT also exist in HW rev1, but floated end).
3. FW not generate CAN_RESET-signal.
4. Makefile FUSEs config: CLKO for clocking MCP2515 not enabled byCKOUT -fuse ("Clock output on PORTC7").
5. Makefile FUSEs config: HWB jumper - exist in rev1 version, but HWBE-fuse (Hardware Boot Enable) is off. For what functionality exist HWB-jumper?
6. TP3, TP4 - for which purposes? (FW dont have any settings for this uC-port pins)

Regards
Doka

[fabiobaltieri]

Hi Doka,

unfortunately I've never written a proper documentation for this project, and I realized it's a bit misleading, but I actually never built the rev2 of this project - that's one of the last commit I did. I'm pretty confident it should work and fixes a couple of design errors I had with the first revision (which I actually forgot about). If you built it you should be able to get it working with a couple of fw modifications.

Let's see, rev1 had two major issues: the MCU was clocked by the CAN controller, but the resets are tied together, and this was breaking the self programming capability of the AVR, with the consequence that I had to lift the reset pin from the CAN controller. Secondary, I forgot to wire the interrupt pin - shame on me for not running the ERC - the firmware just polls USB and CAN continuously anyway and does not do anything else, so the performance impact should be minor.

Now, you probably spotted most differences, and I'll try to remember why I did those changes, let's see:

1. that's correct (I labeled it PWR in the layout), I thought that it would be better to wire the power led to a GPIO so that you know that the board in powered AND the firmware is running.
2. silly me :)
3. yep, see the issue above, just set the pin high after startup and you'll be fine
4. right, you need to enable it so the CAN controller is clocked by the AVR (and ISP will work fine)
5. hardware pin to skip the factory bootloader in hardware, it works with default bootloader but in the end I replaced it with the one from ben-wpan which has better functionality (timeout based loading of the main firmware), so HWB should be disabled
6. those are the AVR UART (tx/rx), may be useful for troubleshooting, just in case (hey! that's they're call test-points after all :-)

So, I think you should be able to use the rev1 firmware on rev2 with really minimal modifications, and it seems you already figured out what to do with fuse... let me know if it works! (and post a picture of the board, it's a bit sad that I've never seen the rev2!)

Cheers.

[iDoka]

Thanks!

Remained unclear point for me:
FW-optimization for INT-signal from MCP2515 handle:
I only need call mcp2515_update_status() from interrupt-handler instread polling mcp2515_update_status() from main-routine while-cycles?

For what purposes for calling mcp2515_update_status() disable interrupt in this code:

  while (1) {
                cli();
                mcp2515_update_status();
                sei();
                buffer_tx_process();
                buffer_rx_process();
        }

Because I planned to add second MCP2515 in future (with additional ~SS-signal for secondary chip select) and I want to prevent frames loss.

[fabiobaltieri]

Yes, that code was written with a proper interrupt implementation in mind, but just by keeping the ISR code in the main loop (with irq disabled), so when you set the interrupt you should only need to call mcp2515_update_status from there.

The reason why it runs with IRQ disabled - if I remember correctly - is that some other code called from the USB controller interrupt directly write to the SPI port (maybe the setup code), and that would create a race condition with access from normal code. I think it may be possible to lock with more granularity, but I explicitly kept that function with irq off from the caller because I wanted it to run unmodified from a real interrupt.

As for the second interface, keep in mind that the micro already has some issue keeping up with a busy 250kbps bus, so I would not add a second interface unless you are working with lower bitrates - it's not enough that the average traffic is slow 'cause the MCP2515 only buffers one packet (or two if you don't care a about out-of-order frames) so it would drop frames during bursts even of a lightly loaded fast bus - that's basically the reason why I did not develop this design further.

Let me know how it goes! (and feel free to post a link to your project!)