1
\$\begingroup\$

I am trying to design a development board with a dialog micro. I am trying to remove the need for a programmer on this board. So that the user could simply plug in a usb cable and be able to communicate with the chip and boot it. I have seen the arduino uses an additional micro (ATMEGA16U2) to do usb to uart and this feeds into the arduino's actual micro (ATMEGA328P-PU). Apologies if the following comes across very stupid but for my own clarifications I have 2 questions:

Firstly, how is the first micro programmed to begin with? I'd imagine the chip comes empty so if I plug a USB at first it wouldn't see anything?

Secondly could I use an FTDI usb to serial chip to do the same thing? Would that not have been a simpler solution?

I am guessing once the communication between my laptop via usb to my micro via uart is initiated, I could then use any IDE to program this chip.

I have very basic prior experience working with micro's and would like to take this opportunity to improve on that.

\$\endgroup\$
9
  • \$\begingroup\$ Small adjustment : they are microcontroller, not microprocessor \$\endgroup\$ Commented Jul 13, 2018 at 9:10
  • \$\begingroup\$ IIRC, ATMEGA16U2 is used to emulate FTDI chip which is more expensive. \$\endgroup\$ Commented Jul 13, 2018 at 9:36
  • \$\begingroup\$ Yes there are many open and probably closed source examples out there of using FTDI chips with the various protocols supported by this and other MCUs (this brand and others). You can get some inexpensive programmers that are often based on an FTDI chip, where someone has made the software for you. But if you are wanting to get into MCUs this is part of it, programming the mcu code itself is 5% of the work between all the reading, mastering the toolchain, solving the preprogrammed or field programming, etc. all combine to cover the rest of the work. \$\endgroup\$ Commented Jul 13, 2018 at 11:59
  • \$\begingroup\$ push comes to shove, buy an arduino or a nucleo or mbed or countless other sandbox solution based tools, and make your own programmer. There are also other products out there, that are factory programmed to support dfu for example. wire them up, set the strap pin correctly, power on or reset and you can program them over usb, remove/change the strap reset and there you go. Others have uart bootloaders built in making a nice mating with an FTDI or other part in a uart mode. \$\endgroup\$ Commented Jul 13, 2018 at 12:01
  • \$\begingroup\$ sounds like you are wanting to take the step from $50 arduino board where you are in a sandbox where everything else including 90% of the programming of the peripherals on the part has been done for you, and wanting to break out into buying the $2 part yourself and using it. Worth the effort but there is effort starting with reading up on the in system programming interfaces, also nothing that the xmegas vs megas and lesser devices dont always share the same protocols in the AVR world. Study the datasheets and app notes. \$\endgroup\$ Commented Jul 13, 2018 at 12:03

3 Answers 3

Reset to default
5
\$\begingroup\$

Firstly, how is the first micro programmed to begin with?

In the factory with a programmer.

Secondly could I use an FTDI usb to serial chip to do the same thing?

The Atmega328 can be programmed using the SPI 'protocol'. To get an SPI stream out of a FTDI chip requires some nifty programming.

Most 'self programming' development kits have a basic boot program in a protected section of their FLASH memory. It is put there in the factory. It has SW to use an interface (UART, USB) which allow you to upload data into the remainder of the FLASH and jump to it. The protocol is proprietary but sometimes disclosed.

I could then use any IDE to program this chip.

No, your IDE would need to know what interface and what protocol to use. Also working with breakpoints and stepping through the code is unlikely to work. It is the reason why forking out some money for a decent (ICE) programmer is worth every penny.

\$\endgroup\$
5
  • \$\begingroup\$ So designing a self-programming kit will be harder than I thought. Someone mentioned I could load the bootloader initially using JTAG tools and then do all subsequent programming by comms via uart using an FTDI chip. So are FTDI chips then not used for micro and comp comms? \$\endgroup\$ Commented Jul 13, 2018 at 9:48
  • \$\begingroup\$ I suppose more importantly then, is there no simple solution to design a 'self programming kit'? One where the developer only plus their laptops to the kit using USB? \$\endgroup\$ Commented Jul 13, 2018 at 9:53
  • \$\begingroup\$ Yes, you can write your own 'boot-loader' and write that with a dedicated programmer. Then use the FTDI/UART to upload images. You also need to write SW on the PC to send an image to a (virtual) COM port. I thought you where looking for a complete 'no programmer' solution. \$\endgroup\$ Commented Jul 13, 2018 at 11:08
  • \$\begingroup\$ ftdi chips can be used to generate various protocols spi, uart, jtag, i2c, custom. the ones that support mpsse make that smoother, but the others can be bit banged. \$\endgroup\$ Commented Jul 13, 2018 at 11:56
  • 2
    \$\begingroup\$ This response misses the point - the question is not about an ATmega target. \$\endgroup\$ Commented Jul 13, 2018 at 17:28
0
\$\begingroup\$

When you buy Arduino, the chip (Atmega8U2/16U) comes already programmed with firmware. It can be updated using DFU protocol, commonly supported by many USB devices. If you buy the chip alone you'd have to upload the same firmware first time using regular ISP mechanism.

Having said that, the firmware in Atmega8U2/16U is simple USB-to-UART bridge, so you can definitely substitute it for FTDI or Silicon Labs hardware bridge.

I am guessing once the communication between my laptop via usb to my micro via uart is initiated, I could then use any IDE to program this chip

Electrical connection between USB and UART using any bridge chip does not mean communication. You need a software running on microcontroller and listening to UART. The software is called "bootloader" and it has to be uploaded first time using alternative method.

For ATMega328P this alternative method is the same ISP used for programming firmware into ATmega8U USB bridge.

However you are using Dialog microcontroller which seems to be some Cortex-M0 variant. The documentation on Dialog site requires registration, so I cannot see it. From this document it appears Dialog MCUs use complex mechanism with two bootloaders, one of which can be replaced with your own, another seems to be burned into OTP (One-Time Programmable) memory at the factory.

If that is the case then connecting USB to UART port with FTDI would be sufficient to start development. Alternatively you can use JTAG to upload your application directly into RAM (so called development mode in the documentation)

You have to figure it out yourself if you have access to documentation. There is some information here

So that the user could simply plug in a usb cable and be able to communicate with the chip and boot it

There is some problem with terminology here. When you say "the user" do you mean yourself or "end user"? Because end users do not "boot the chip", they plug the device into USB port (or supply power by other means) and it boots itself.

Whether or not they will be able to communicate with it depends entirely on the software you upload. Without that software they (or you) might be able to communicate with existing bootloader and upload their own programs, as discussed above.

If under "communicate" you mean something different than uploading application from IDE then FTDI chip won't help you. For example, you you want to support DFU protocol (so end users could update software easily), or if you want your device to appear on the PC as something else (e.g. input or storage device) then you have to change USB device class. You cannot do this with FTDI chip.

UPDATE

As @chris-stratton stated in the comments below, it is highly advisable to add at least a placeholder for SWD (10-pin Cortex Debug Connector), even if other programming methods available. It will save you a lot of headaches in the long run.

\$\endgroup\$
7
  • \$\begingroup\$ For a Cortex M0 target, it would be a regretful mistake to design a board that did not break out the SWD signals, regardless if another method like a USB or UART bootloader is supported. Most of ST's discovery and nucleo eval boards for example have a 2nd micro on board that functions as a USB-SDW programming and debug adapter, and in some cases also provides a runtime UART interface to the target. \$\endgroup\$ Commented Jul 13, 2018 at 17:30
  • \$\begingroup\$ "the firmware in Atmega8U2/16U is simple USB-to-UART bridge, so you can definitely substitute it for FTDI or Silicon Labs hardware bridge" -- it should perhaps be noted that most clone Arduinos (particularly the lower cost boards sold by Chinese vendors) do make this substitution. And usually not with a genuine FTDI chip, either, which often means spending a while tracking down an appropriate driver before you can use it. \$\endgroup\$ Commented Jul 13, 2018 at 17:36
  • \$\begingroup\$ @ChrisStratton "severe mistake to design a board that did not break out the SWD" - Agree with this 100%. Don't understand why you immediately undermine the above statement with the reference to second micro. The OP goal, as stated, is to simplify the design and avoid special programming interface. Having SWD header and FTDI chip is sufficient for most tasks, except those requiring device class change. \$\endgroup\$ Commented Jul 13, 2018 at 17:39
  • \$\begingroup\$ @Jules A lot of Arduino clones actually getting by with just ISP header. DIY and breadboarded Arduinos certainly follow same way. \$\endgroup\$ Commented Jul 13, 2018 at 17:44
  • \$\begingroup\$ @Maple - because putting the SWD and USB serial in an onboard micro theoretically means they're available to even newbie users. Though nothing with USB even ends up straightforward... \$\endgroup\$ Commented Jul 13, 2018 at 18:14
0
\$\begingroup\$

Both Arduino and NodeMCU uses a USB to UART bridge chip, like FTDI, and both uses aditional control lines (CTS RTS) to control reset and/or boot selection pins of the target uC, in this way you can reset the target uC and also put it in bootloader mode, where a special software inside the uC will be in charge of receive the new code thru serial and burn it into flash. In the case of Arduino, as already stated, this bootloader code need to be previously burned into the uC thru a standard programming interface

But in the case of NodeMCU (ESP8266) the bootloader is already present in the ROM memory (and will always be there, is not possible to erase it) so the PC software force the ESP8266 reset (thru CTS), and use the RTS signal (attatched to another IO) to force the ROM bootloader to start, then the application uses the bootloader protocol to send the new code to be flashed.

I already worked with STM32 Cortex-M3 microcontrollers, and they also have a ROM bootloader which are selectable at reset time thru a signal in one of the IOs, so in theory is totally possible to do a STM32 "arduino board" that works exactly in the same way of a NodeMCU-ESP8266, not requiring any pre-flashed bootloader and also not being "brickable", as the bootloader will always be accessible.

\$\endgroup\$

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.