CoIDE, STM32F103 and Semihosting

I have been a little quiet lately as I have been working on a few projects. One of these are some experiments with the CooCox CoIDE and a STM32F103 dev board that I picked up off EBay a while back.

As a quick background, I have generated the bulk of the test project(s) with STM32CubeMX, and then modified what I needed. It should be noted that STM has updated the StdPeripheral library with a new HAL Library, which I decided to use. CoIDE has a neat feature called “semihosting” which allows you to shoot debug messages back to the IDE via the JTAG interface, freeing up the UART for your application-specific use.

The problem comes when adding semihosting. You need to add the “Retarget printf” component as well as the “Semihosting”. A quick implementation of PrintChar() in the semihosting code:

#include <semihosting/semihosting.h>
 
void PrintChar(char c)
{
  SH_SendChar(c);
}

If you try and compile this, you get the following error:

[cc] Starting link
[cc] arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -g -nostartfiles -Wl,-Map=cdctest.map -O0 -Wl,--gc-sections -LC:\CooCox\CoIDE\configuration\ProgramData\cdctest -Wl,-TC:\CooCox\CoIDE\configuration\ProgramData\cdctest/arm-gcc-link.ld -g -o cdctest.elf ..\obj\stm32f1xx_hal_rcc_ex.o ..\obj\semihosting.o ..\obj\stm32f1xx_hal_pwr.o ..\obj\stm32f1xx_hal_can.o ..\obj\stm32f1xx_hal.o ..\obj\stm32f1xx_it.o ..\obj\stm32f1xx_hal_dac.o ..\obj\stm32f1xx_hal_gpio_ex.o ..\obj\stm32f1xx_hal_wwdg.o ..\obj\stm32f1xx_hal_cortex.o ..\obj\stm32f1xx_hal_crc.o ..\obj\stm32f1xx_hal_iwdg.o ..\obj\system_stm32f1xx.o ..\obj\stm32f1xx_hal_rcc.o ..\obj\stm32f1xx_hal_dac_ex.o ..\obj\stm32f1xx_hal_adc.o ..\obj\stm32f1xx_hal_i2s.o ..\obj\stm32f1xx_hal_smartcard.o ..\obj\stm32f1xx_hal_pcd.o ..\obj\stm32f1xx_hal_uart.o ..\obj\usbd_core.o ..\obj\main.o ..\obj\startup_stm32f103xb.o ..\obj\stm32f1xx_hal_usart.o ..\obj\stm32f1xx_hal_nor.o ..\obj\stm32f1xx_ll_usb.o ..\obj\printf.o ..\obj\stm32f1xx_hal_spi_ex.o ..\obj\stm32f1xx_hal_cec.o ..\obj\stm32f1xx_hal_hcd.o ..\obj\stm32f1xx_hal_flash.o ..\obj\stm32f1xx_hal_gpio.o ..\obj\stm32f1xx_hal_dma.o ..\obj\usbd_desc.o ..\obj\usbd_conf.o ..\obj\stm32f1xx_hal_adc_ex.o ..\obj\stm32f1xx_hal_irda.o ..\obj\stm32f1xx_hal_sd.o ..\obj\sh_cmd.o ..\obj\stm32f1xx_hal_spi.o ..\obj\syscalls.o ..\obj\stm32f1xx_hal_i2c.o ..\obj\stm32f1xx_hal_msp.o ..\obj\usb_ctrl.o ..\obj\stm32f1xx_hal_eth.o ..\obj\stm32f1xx_ll_fsmc.o ..\obj\usbd_cdc.o ..\obj\stm32f1xx_hal_rtc.o ..\obj\stm32f1xx_hal_tim.o ..\obj\stm32f1xx_hal_flash_ex.o ..\obj\usbd_ctlreq.o ..\obj\stm32f1xx_hal_pcd_ex.o ..\obj\usbd_cdc_if.o ..\obj\stm32f1xx_hal_nand.o ..\obj\usbd_ioreq.o ..\obj\stm32f1xx_hal_pccard.o ..\obj\stm32f1xx_hal_sram.o ..\obj\usb_device.o ..\obj\stm32f1xx_hal_rtc_ex.o ..\obj\stm32f1xx_hal_tim_ex.o ..\obj\stm32f1xx_ll_sdmmc.o -lm -lgcc -lc
[cc] c:/program files (x86)/gnu tools arm embedded/5.3 2016q1/bin/../lib/gcc/arm-none-eabi/5.3.1/../../../../arm-none-eabi/lib/armv7-m\libc.a(lib_a-impure.o):(.data._impure_ptr+0x0): multiple definition of `_impure_ptr'
[cc] ..\obj\printf.o:(.data+0x428): first defined here
[cc] collect2.exe: error: ld returned 1 exit status

It turns out that after a lot of googling, pulling out of hair and cursing, the answer is rather simple. It seems that the struct “r” and “_impure_ptr” are being redefined in printf.c; so we just need to comment them out from the printf.c file in our project:

#include <semihosting/semihosting.h>
 
void PrintChar(char c)
{
	SH_SendChar(c);
}
 
/** Required for proper compilation. */
//struct _reent r = {0, (FILE *) 0, (FILE *) 1, (FILE *) 0};
//struct _reent *_impure_ptr = &r;
 
...

Rebuild and problem solved.

Avoiding Panic

This is a re-post of a comment that I made on my Facebook profile a couple of months ago regarding the temporary dumping of raw sewage into the local river by a city near where I live. There was a fair amount of buzz around this issue, which in the end, I can understand the need to discuss, but was seemingly blown out of proportion.

I’d like to preface this with saying I am totally, 100% against the dumping of raw sewage into our rivers and lakes as a policy. And 8 billion liters sounds like an awful lot of raw crap to be dumping in our river. The St. Lawrence flows at a rate of approx. 16800 cubic meters per second. This is the amount of water if you picked a point along the river and measured the volume of water that passed across that point in 1 second. And that’s every second (and it obviously changes with seasons). So how long will it take to “flush” the 8 billion liters of crap the City of Montreal wants to dump in the river? Well, there are 1000 L in 1 cubic meter, so 8 billion liters can be converted to 8 million cubic meters (still horrifying!). To find out how long it takes the St. Lawrence to move 8 million liters, we divide 8 million by 16800, which gives us… 476 seconds. That’s about 8 minutes. I believe the City wants to dump this sewage over a 1 week period, so if we assume they do it evenly (which of course is a guess, I’m sure it will vary), that means 8 million cubic meters divided by 7 days, giving about 1.2 million cubic meters per day. Divide that by 24, you get 50000 cubic meters per hour. Divide that by 60, you get 833 cubic meters per minute. Divide /that/ by 60, and you get about 14 cubic meters per second. That’s a lot of crap. But considering even if the 16800 cubic meters per second flow rate is off by 100 (so 168 cubic meters per second instead), the river will wash that crap towards the ocean in about 1/100th of a second after dumping it.  This is a travesty if it were done on a daily basis as a policy. But as a once in a while thing?  I’m not so sure it’s all that important to get terribly worked up over. I will leave it to you the reader to figure out where that sewage would normally go if it was extracted from the waste water when all the sewage handling systems are working. The answer might surprise you.

 

PCBs in the Wild!

I have been working on a couple of prototyping boards for general “hey I need a PCB for this oh I have one here” type of projects. Since I’m working more with Surface Mount Technology (SMT) these days and have more of those part in my “stock”, I designed some prototyping boards with this in mind:

PMWVqK05NScwOySx7d_rqpRDDEQCtxBRgKVb5fMP5_Y

w8qOk0l8Cf6-VvLJCz_le5dyH_54Me0o0eiwX4rdkM8

I have sent a few of these to some people that I chat with on the #eevblog IRC channel, and one of them was kind enough to send me an “action shot” of a little LED-based project he used my PCB for!

WP_20150906_16_12_12_Pro

And another one from c4757p:

pcb-in-the-wild-2

 

Macro Rings and Test Shots

I’ve been into photography for many many years. A long time back, when I first started, I acquired a macro lens. This was essentially a regular lens but with an adjustable bellows on it. I have not had any kind of macro lens since then, and now that I’m getting back into documenting some of the work that I’m doing in electronics, I decided to “spring” for a set of macro rings:

IMG_5772

And this is what they look like attached to a lens:

IMG_5773

(you can use any lens; the focal length of the lens used will make a difference on the magnification that you end up getting)

And a couple of test shots I took with the rings:

IMG_5770 IMG_5769

Power Designs Inc 6050C Display Mod

Here’s a modification that I have been meaning to do for a while. It involved replacing the PCB in one of my power supplies with a modified version designed by me that upgraded the size of the 7-segment LED display.

IMG_5736

I ordered the board from OSHPark. My experience with them has been positive; the turn around time was about 2 weeks and the gold finish is very nice. I’m fine with the colour of the solder mask, however note that the mask is a matte finish rather than the typical “pearl” or “glossy” finish that I am accustomed to seeing on PCBs. Not a big deal, but something to think about. Also, the traces are a bit difficult to see through the solder mask.

IMG_5737 IMG_5739 IMG_5741

I of course did not fully check my notes when throwing together the schematic for this project which resulted in the boards I received having the ‘a’ and ‘g’ segments reversed. A few cut traces and a jumper wires later and all was working as expected.

IMG_5745 IMG_5744  IMG_5742IMG_5743

I originally tried to think of a better way of re-attaching the new display board to the existing display measurement/logic board, but in the end the simplest solution won out and  I just re-soldered the new display board back. The header pitch is 3.81mm and was a total pain to find (yay eBay!).

IMG_5746

The end result is a bright, clear and LARGER display. Here I have contrasted it with the model right after the 6050C, the 6050D which has a larger digital display (and also does not display the measurement mode as the 6050C does, E or I).IMG_5748If I decide to pick up any more of these supplies, I think I’d make the same display modification to them as well. I have been looking at the 6050A models (which can usually be had for cheaper): these might also be good for a “digital makeover” involving removing the analog meter and designing a new digital display PCB.

 

Tektronix DMM 916 Back-light Mod

In keeping with the theme of back-light mods, I have another one here for you all. Recently I was able to get my hands on a well-loved (read: had the piss kicked out of it) Tektronix DMM 916. The specs are nice:

  • 4.75 digits
  • 40,000 count
  • Basic DC accuracy of 0.06%+1 count

The only problem which I didn’t know until I got the meter in my hands was that the back light was horrible:

IMG_5669

Wait, where is that back-light?IMG_5671

Still can’t see it? Turn off the lights!IMG_5670

I’m not sure if this is “factory standard” or just a sign of the age of the unit, but either way it needed some change. The first thing I did was to open up the meter and check out the display:

IMG_5675

There is a small slot on one side of the display assembly where the lamp bulb pokes into the light pipe. At first I thought I might use a standard through-hole LED, but realized that I wouldn’t be able to mount it without either cutting the trace (for the limiting resistor) or cutting the display. I didn’t want to mod the board, in case I or someone else wanted to restore it back to a incandescent bulb. So I choose to use a SMD chip LED and resistor, and build it “tee-pee” style on the top of the display PCB, so that the LED and resistor would stick up vertically into the display light-pipe recess:

IMG_5679

The LED is blue, Digikey part number 475-2816-1-ND with a 270ohm current limit resistor. The bulb sank about 20mA while the LED uses ~18mA, so a bit more efficient. I’m still not sure about the blue, but I figured it matches the theme of the case, so why not:

IMG_5680

And as is evident, it is much brighter even with the lab lights on. Curiously, it is not much more legible in the dark in terms of the digits on the screen as I would have thought.

HP8642B Signal Generator Mod

A quick mod post here. I saw this post by Kerry Wong, and having the same hardware myself (and finding the backlight ridiculously dim) I thought this mod was a great idea and wanted to try it myself. First, here is a shot of the original backlight:

HP8642B-OrigBL

I pulled the front panel apart, and decided to use white SMD LEDs for my replacement mod:

IMG_5664

After soldering up everything and reassembling (and of course cursing a lot due to the number of defective white LEDs that I didn’t realize that I had), the result is beautiful!

 

HP8642B-Mod

And here is the same Easter egg that Kerry found (hold down the MSSG key while powering on the unit):

HP8642B-ModBL1

 

Function Generator Shenanigans

So my problem turned out to be not the saving of the status of the HDG2002, but actually doing the following:

  • Go to Utility, select System Status
  • Toggle the “Startup” option to “Last” (to set the function generator to restore to the last setup before power-off I assumed!)
  • Exit back to the main channels screen
  • Power Cycle the generator using the power button on the front panel.

When the HDG2002 reboots, POOF! No more main screen after the Hantek logo briefly flashes on screen. So what happened? It turns out that the problem is actually that the BACKLIGHT is set to level 0 by doing the above procedure. I found this out by logging into the serial console and finding the /dso/app directory. In here, there are a couple of “test” binaries:

test_beep
test_bkl

I tried them both but the test_bkl was the interesting one. When I ran it with the following options:

./test_bkl on 105

Poof the display popped back on! Of course on reboot it turned back off again. So after temporarily re-enabling the backlight, I went back into Utility -> System Status -> Startup and set it to Default, power cycled and boom, back in business no worries.

Well I guess there are still a few bugs in the firmware.  Please note that you can run into this bug REGARDLESS OF WHETHER YOU CRACK THIS FUNCTION GENERATOR OPEN OR NOT, and it has nothing to do with modifying the HDG2002. Except that if you don’t crack it open after you do this, you seemingly have no way to recover.

Hope this helps someone else!