Category Archives: Programming

Testing app almost done

Posted on by
1

Testing procedure of Argon drives is ~80% done now. The testing system consists of:

  • Hi-pot tester which verifies insulations at 1.5 kV AC voltage
  • Testing hardware (artificial test load, various I/O testers, etc)
  • Testing software for the above hardware
  • Test functionality in firmware

The testing software is based on Granity with some modifications.

Argon testing application work in progress

Argon testing application work in progress. Most of the UI stuff will be ripped off from the polished testing version and instead provide only a simple “start test” button to eliminate human error.

I will start testing the first drives as soon as the test software fulfills it’s all technical requirements and bring first drives to market ASAP. Polishing the software for assembly house can wait couple of weeks as it will affect only next production batches.

Blinking LEDs

Posted on by
11

Argon has two programmable front panel LEDs that indicate the state of drive. Having just 2 LEDs is challenging as there are more than dozen different states that need to be distinguishable. The current solution looks like this.

The present way is to assign orange led solely for faults and green led for motor control sate. To fit large number of states in reasonably short and easy to read blinking sequences, we’re blinking them by combinations of short and long flashes. One state for example can be repeating pattern of short-short-long-pause and another long-long-short-short-pause.

LED blinking example. The sequence here is long-short-short-pause.

LED blinking example. The sequence here is long-short-short-pause.

The Wiki page (link above) has animated images from each combination making them hopefully easier to identify. What do you think about this approach (please leave a comment)? Another alternative I have been pondering is just flashing led certain number of times. Such as one state is 3 flashes, another 4 flashes. The problem is counting reliably something like 15 flashes.

Meanwhile in production: the first release candidate Argon batch should arrive any time now! Last week factory reported mistake of getting wrong type of bridge rectifiers which caused 2-3 days delay to planned schedule but drives should definitely arrive this week for final testing.

Status

Posted on by
Reply

Today we finished programming the Argon microcontrollers and sent them back to the assembly house. Production will start once all remaining components have arrived to the factory. We’re still waiting enclosures, should be less than a week away.

Chips being programmed in a clam shell socket

Chips being programmed in a clam shell socket. The chips are handled with a vacuum pen. The environment  is made ESD safe to prevent expensive errors.

Meanwhile I designed a testing procedure for the new kind of USB adapters that are produced same time with Argon drives. One SimpleMotion V2 USB adapter is necessary to configure drives and it may be also used to create PC based motion control applications for them.

SimpleMotion V2 USB adapter

SimpleMotion V2 USB adapter

Resetting STM32 option bytes

Posted on by
7

Without too much thinking I wrote a code to Argon’s STM32 ARM processor that write protects its flash content. After a minute I encountered a problem that I was unable to program anything new to the chip as it protects writing into memory also with a debugging tool effectively bricking the device. It took an hour to figure out how to restore the chip option bytes that determine if the flash memory is protected or not. JLink’s small utility that is supposed to restore STM32 option bytes didn’t appear to work for write protection so alternative solution was necessary to avoid replacing the chip on PCB.

After some googling (found this useful forum post) and reading chip data sheets I figured out how to do it manually with JLink Commander tool. I’m posting JLink command list here as I’m sure there are people needing this info, too.

(unprotect option bytes)
w4 0x40023c08,0x08192A3B
g
halt
w4 0x40023c08,0x4C5D6E7F
g
halt

(restore non-write protected state. one could also reset other option bytes here such as read protection or brown out reset settings by modifying the next line)

w2 0x40023C16,0xffff
g
halt

(write option bytes)
w1 0x40023C14,0xef
g
halt

I’m not sure if g and halt commands are necessary but used them just in case. This should work at least with STM32F2 series and probably also STM32F3 and STM32F4 chips too.

JLink Commander when unlocking STM32F2 write protection

JLink Commander screenshot after unlocking STM32F2 write protection

Precision crafting of the Bootloader

Posted on by
Reply

Bootloader (a.k.a. IAP = in application programmer or DFU = device firmware upgrader) is a piece of software in microcontroller to make programming of a new firmware inside the device possible without accessing the chip physically with a programming tool. In Argon’s case firmware upgrade will be possible through the SimpleMotion port and Granity software.

I have spent couple of last days finalizing the bootloader of Argon. Even though the amount of code is small, it must be written with extreme caution because a bootloader bug could lead to bricked device that need to be re-programmed in the factory, or worse, induce permanent damage to hardware. Bootloader is also the part of software that cannot be upgraded by the end user, so we have no change to fix the possible bootloader mistakes remotely after devices are shipped.

In our goals, bootloader must be robust enough to make it impossible to brick the device. This includes the cases where incorrect or corrupted firmware is being sent, or power is being cut in the middle of the firmware upgrade process. Bootloader should be also tolerant for some hardware errors, such as broken crystal oscillator.

Sneak peek to Granity servo tuning software

Posted on by
2

One of most important parts of the project is the Argon configuration tool Granity. The tool was originally named as GDtool 3 but that name was ditched as the software has been completely redesigned & rewritten – no single line of the old code has been spared.

 “Make everything as simple as possible, but not simpler” – Albert Einstein

The main focus during design of Granity is to eliminate confusing parameters and make it harder to use it wrong. I.e. the software will notify user if one forgets to click Apply button before doing step response tests. Also the parameters causing most confusion in GDtool 2.x are replaced by more understandable ones.

Surprisingly, simplifying the usage also simplified the source code. GDtool 2.5 consists 15 800 lines of code while Granity consists only 6 500. I call that progress!