Custom ARTIK 710 Boards
In this first article in a series of unknown breadth or depth about building devices based on Samsung ARTIK, I’m going to give an overview of the things I learned, especially some things I wish would have been easier to find, while building custom boards around Samsung ARTIK. I have only used the 710 module, so I’m not going to be able to speak to those directly, but there is surely a fair amount of crossover.
This is a living brain dump article. As I learn more, I’ll fill in more detail. And hopefully organize it a bit. In other articles I cover the kernel, boot loader, OS, and image building aspects of custom ARTIK 710 boards.
The official documentation is geared towards early prototyping and makers. One of the first things unexpected things I encountered was: though Samsung obviously expects/designed these modules to be used on custom boards, almost all of the documentation is very specific to their development boards. I get this, but I think a little more help for folks putting these on their own boards would go a long way. Really, it was just an invalid assumption on my part going into things. I’m guessing the professional engineers integrating this module are just doing the work and getting the job done. The knowledge doesn’t make it out of their organizations or maybe even their heads.
The on-module RTC is broken. I don’t remember where I read it first, but now there’s a thread on the ARTIK forum that has some info. The RTC that’s on the module is disabled. A Samsung employee on the forum writes, “RTC present on module is working well but it needs ARTIK module to be always powered up. Where as external RTC can be powered by battery(coin cell).” There ya go. The development board uses a Maxim DS1337 and a rechargeable coin cell.
The docs are wrong about pin voltages. It was only a couple hours after clicking the button when got that special sinking feeling. That feeling when you realize you designed to an assumption that was invalidated by the datasheet you should have read about two weeks ago, and you just burned at least a few thousand bucks and a couple weeks.
Anyway, it wasn’t a datasheet in this case, it was some documentation from the ARTIK developer site, which states:
In one group of ARTIK 520 and 1020 programmable pins, those associated with port GPX0 / module names XEINT 0–6, the pins are 3.3V-tolerant. The ARTIK 530 and 710 modules have many such pins. Characteristics of these pins:
When programmed to drive an output, it will be only to 1.8V.
When programmed as inputs, external circuits can apply 3.3V without a requirement for intermediate buffers.
Refer to “Type B” pins in the ARTIK 520 or 1020 Datasheets, or search for “Characteristics GPIO” in the ARTIK 530 or 710 Datasheets, for additional details.
All other programmable pins support operation at 1.8V only, or as noted in the Datasheet.
When it comes to the modules themselves, this biz is misleading! I am pretty sure they’re referring to the outputs on the GPIO board that’s part of the developers kit. But the modules themselves don’t have pins with these names, and furthermore, have different voltage characteristics. I think the GPIO board has a GPIO expander that has different voltage properties and they put a bunch of level translators on the board to make that work. But for integrating the module itself with your own design, the module datasheet is correct.
Sometimes you have to design into the module. The module datasheet is at times skimpy on info, and pin voltage is one of those cases. The datasheet specifies pins as being “3.3V” or “1.8V” or whatever, but it doesn’t say whether it means 3.3V tolerant or 3.3V logic (which was only a question in my mind after reading that bogus documentation). In these cases, you have to dig into the SoC reference manual, and until you’ve started cranking on the kernel or bootloader, you won’t have any idea what chip is inside the shield on the module. Software topics are further down the page, but the ARTIK 710 uses the Nexell S5P6818 SoC (datasheet). Much of the module datasheet was copied directly from the SoC datasheet, but sometimes there’s just a little more information in one or the other. Best to have both on-hand.
The developer board is a pretty good but not 100% reference design. The board designs are not bad, but they are designed to support a wide variety of possible uses, and that results in things that would be needless for most specific uses. For instance, there are a bunch of external power supplies and level translators. Blindly copying the design will result in waste.
And yet, following the design of the developer boards in some places, in particular for accessory ICs like the RTC and for the HSIC USB, will make things easier once you start trying get the board running, because the bootloader and kernel config will just work. Unfortunately, some parts, such as the ALC5658 audio codec, are just not available from domestic distributors. But for stuff like the DS1337 RTC, it’s easy to throw in the same part and save some trouble.
Pay attention when reusing pins. It’s easy, tempting even, to run down the datasheet and make pin assignments— it makes sense to start on GPIO_A0 and work your way up, right?
The module is going to come pre-programmed with the same software that runs on the developer board, configured for the developer board circuitry. While it’s not hard to make sure the first boot on the board is from your updated image via external MMC or USB or whatever — it’s also not hard to accidentally power up a board without setting it for external boot. I got lucky in my first design but I didn’t think about this stuff until I was working on the kernel and a few grand was already spent on boards. Wherever possible, make sure the default config isn’t going to pop chips.
Don’t connect the on-board LDOs to each other or any other supply. This is probably common sense, and none of us would do it in a design. It’s not too dangerous — it’s not likely to cause damage — but the PMIC shuts everything down and/or won’t power on when you do it.
In the first ARTIK board design I did, I connected the VDD of an SD card slot to one of the LDO outputs that is disabled by default. When I was bringing up the board, I realized I had a chicken and egg scenario — I needed to run code (U-Boot or Linux) to enable the LDO and power up the card, and I needed the card powered to put new code into the module. So I jumpered the SD power bus to the main 3.3V DC/DC output and the board wouldn’t power on. And I had buried the entire trace and didn’t use a 0 ohm resistor, so there was nowhere I could cut. I had to get in there with the iron and bend the pin up.
As part of that I learned that the MMC interface on the ARTIK 710 performs pretty well even without pullups, because they were also connected to the SD power bus and had to go.
You’re probably not going to JTAG the board. I put a JTAG port on my first prototype. I guess you never know, and I put the lands for one on boards when it’s practical, but I’ve never needed it.
Pull the PWR_KEY pin low to make the thing automatically boot. If your device is a simple “on whenever there’s power” device, then you don’t want require the user to push a button.
The forum site is not as active as I had expected. I guess I expected more traffic. But replies seem to come in pretty quickly, and usually you’ll hear back from a Samsung employee.
The silicon requires a drop of power to change boot mode. If your design uses a button to allow the user to trigger an SD or USB boot, bear this in mind. I like to make one of the user buttons double as a recovery mode button, so that if the user plugs in/powers on the device with that button held, it will skip eMMC boot. This works great, by the way, but with this paragraph’s caveat. If the device is set up as always on (PWR_KEY pulled low), then the user already has to kill the power to switch to recovery mode. But if you’re using PWR_KEY with a button, your instructions will need to include unplugging the power(or doing some fancy circuit stuff).
This crosses over into important software implications as well. Consider this scenario:
Recovery mode boots from SD into U-Boot and runs the sd_recovery command (written by Samsung — and extended by yours truly at Hi-Z Labs to support large image files without using the uInitrd/SD fuse process— in the u-boot-artik repository), which partitions and writes image files to eMMC. After sd_recovery the newly-imaged eMMC is directly booted. That all works fine. But what if at some point after this, the OS reboots, even hours later, but before the power has been bounced? Well, to our dismay, the module will again and still skip eMMC boot.
This can be mitigated by software — if the recovery SD card is still connected (and your board has a GPIO line connected to your boot switch, as is the case in my dual-purpose button), you could put a check in the U-Boot boot command to see if the button is active, and conditionally skip recovery and boot from eMMC. But, if you’re also depending on the U-Boot environment specific to your boot medium, as is the case when running Mender, U-Boot would use environment from the SD card instead of the one in eMMC.
A clean solution is to perform recovery, then display the message and halt. This is what the SD fuse process does, though the message is printed to the serial console.
There is not an official CAD library available. It would be great if there were, because there are a lot of pads on this beast. It looks like Samsung used Allegro to do the design, so if you use that you might be able to pull the symbol and footprint from the files out on the documentation side. For everyone else, SnapEDA has a clean library. This is what I use. They break the module symbol into blocks to make it easier to place around the schematic.
More to come!
I’ll keep updating this as stuff comes to mind and/or I have time to add on. Let me know if you have any questions you’d like to see answered here.
