USB 14K50 uC operation

[Jerry Messina]

Is there a reference as to what functions the 14K50 uC performs? It appears to be used to communicate with the main PIC24 via the UART, so I assume there's a bootloader in the main PIC24 that allows you to download programs?

I assume the Console module works in conjunction with the 14K50 to give you a USB CDC interface. How do you get the 14K50 in and out of "download/programming mode". If using the thing as a "normal serial port", is there anything we should know (ie don't send "xxx" or it'll erase the program)?

It also has a connection to the PIC24 MCLR signal so it can reset it. What controls/generates this?

[majenko]

The PIC18 is just a dumb CDC device. It doesn't do anything "special" other than interpret the DCD signal as "reboot the main MCU" - just like on the Arduino.

It's the bootloader on the main MCU that does all the magic. At first boot it looks for a specific character signal from the host computer via UART. If it sees it then it starts the programming sequence, if it doesn't it just skips on and starts the main program. From what I remember that initial character is 0x80, so if you are sending 0x80 while the main MCU is rebooting then it will enter programming mode. That phase only lasts a fraction of a second anyway, so it's quite unlikely that would ever happen.

[Jerry Messina]

It doesn't do anything "special" other than interpret the DCD signal as "reboot the main MCU" - just like on the Arduino

Thanks, Matt. That's the missing piece of info I was after. That's good to know.

So, the firewing board resets when you connect up to it with a terminal emulator. Unfortunately, it seems to stay that way. It doesn't appear to do that when using the IDE serial communicator.

[majenko]

It's the same way the Arduino operates. The firewing loader program fwloader.exe has a special option to tell it to assert the DCD signal. There are ways in software of opening a serial port without asserting that DCD signal, but I'm not sure how. It varies from OS to OS of course...

If you want to avoid the reset you just need to add a capacitor between the RESET and GND pins on the board. I use a 22µF one as I have lots around, but anything of around that value or greater works fine.

[David John Barker]

Matt has pretty much covered the operation of the main board. As he points out, the onboard 14K50 has a very simple program which just exchanges data between the 24F device. It also uses DTR to reset the main MCU.

The loader is written in ASM and is open source. I will eventually get it onto firewing.info site, but in the meantime If you want a copy just email me. The 14K50 code is written in Firewing (using Swordfish as a code generator). However, the code is very simple and you could probably put together a native Swordfish version in about 10 minutes. The core is based around the Swordfish CDC library modifies by Jerry some time ago. Again, if you want a copy of the source then let me know.

> terminal emulator. Unfortunately, it seems to stay that way.

DTR stands for "Data Terminal Ready" and true terminal programs will assert DTR to inform the target that it is ready, so will force the board into a permanent reset state. Personally, if not using serial communicator, then I would try and find a terminal program where you can control what DTR does.

[majenko]

Yeah, DTR... I meant DTR... Always get those confused

[Jerry Messina]

A number of term packages I use don't allow control of DTR... it's handled automatically.

I usually use the CDC OnControl event to detect a change in the CDCControlSignal state. That way, it's easy to detect when
a terminal first connects. In SF, I do something like...

Code: Select all

dim term_stat as byte

// USB CDC connection event
// RTS and DTR control lines
// The states of these lines are controlled by the USB Host
// The default values are RTS=0 and DTR=0.  In Windows, when a typical
// terminal program opens the COM port, both RTS and DTR go to 1.  When
// the program closes the port, DTR goes to 0 but RTS remains at 1
//
const DTE_PRESENT = $03           // RTS (bit 1) + DTR (bit 0)

event OnControlHandler()
   if (CDCControlSignal._byte = DTE_PRESENT) then       // terminal present
      term_stat = DTE_PRESENT
   endif
end event


main:
   term_stat = 0
   
    CDC.OnControl = OnControlHandler

   while (true)
      if (term_stat = DTE_PRESENT) then
         // allow the host a chance to init its terminal app window, etc
         delayms(500)

         // display startup message
         console.write("Hello")
         
         term_stat = 0
      endif
      
      // handle CDC comms
      ....
   end while


This seems to work ok with the majority of them.

[David John Barker]

That's pretty much what the main board is doing:

Code: Select all

      ' look for a DTR event   
      if Cdc.DTR = 1 then
         low(resetPin)     
      else         
         high(resetPin) 
      end if 

which pulls the reset pin low, resetting the MCU. This is a very popular technique for boards along the lines of Firewing. If you want to use a terminal program which asserts DTR, then you need to disable this feature. Matt has suggested a hardware solution. For software, you need to re-program the 18F14K50 to ignore the DTR line. You will of course need to manually reset the main board to initiate a bootload sequence.

If you email me I can send some USB firmware which ignores DTR so you can re-flash the 18F14K50. Just plug a PicKit 3 into the ICSP header furthest away from the main MCU and you should be good to go...

[Jerry Messina]

>That's pretty much what the main board is doing
Doesn't that keep reset asserted while DTR is true?

If it just pulsed reset low for a few us when DTR was first asserted might be an alternative. You'd still get the micro to reset when the terminal connection was opened, but it'd still work with most canned programs that don't have the feature to control DTR.

Having that large a cap on the MCLR line would give the ICSP fits, and could cause power up/down issues as well.

Luckily, I've never used an Arduino. I can see some of the advantage of the way the board operates, but there's also some downsides. Having the board reset when you hook up to talk to it is a big one in my book, but that's just my opinion.

[David John Barker]

> If it just pulsed reset low for a few us when DTR was first asserted might be an alternative.

That's a good idea and probably worth looking in to. I received you email and have sent you all the firmware source. However, I think I could make the modifications here without much difficulty. If I make the changes, is it something you could test out for me?