-
If so, your issues are likely with the opensource software. The hardware side (of SWD) is certainly working, as the ST-Link Utility shows.
-
Opensource stlink software: https://github.com/texane/stlink
Also used this in the past. These days I mostly use openocd, which has less issues in combination with ST.
-
If it helps, I can post adc / random number generator code I used in a separate thread.
The code itself is fairly simple. But it helps if you break it down into individual modules.
-
I managed debugging in Mac OS X now. It is as simple as suggested - starting with booting into bootloader. Then st-link works in Linux/Mac as well and it is possible to step through the code, look at the variables, ...
Some more code snippets?
How about pushing the frequency from 8 to 48 MHz, and set ADC to the internal 14MHz HSI clock?
Code: [Select]// ---- Setup PLL for 48 MHz :) ----
RCC_DeInit();
RCC_HSEConfig(RCC_HSE_OFF);
RCC_PLLCmd(DISABLE);
RCC_PLLConfig(RCC_PLLSource_HSI, RCC_PLLMul_12);
// Flash: 1 WaitState for 24MHz < SysCLK < 48 MHz
FLASH_SetLatency(FLASH_Latency_1);
FLASH_PrefetchBufferCmd(ENABLE);
// Set ADC clock to internal 14MHz HSI source
RCC_HSI14Cmd(ENABLE);
RCC_HSI14ADCRequestCmd(ENABLE);
// and turn the PLL back on again
RCC_PLLCmd(ENABLE);
// set PLL as system clock source
RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK);
// ---- End of Setup PLL for 48 MHz :) ----
ADC looks like this with Standard Peripheral Lib:Code: [Select]GPIO_InitTypeDef GPIO_InitStructure;
ADC_InitTypeDef ADC_InitStructure;
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOA, ENABLE);
RCC_APB2PeriphClockCmd(RCC_APB2Periph_ADC1, ENABLE);
// ADC-init for Temperature probe
ADC_DeInit(ADC1);
ADC_InitStructure.ADC_Resolution = ADC_Resolution_12b;
ADC_InitStructure.ADC_ContinuousConvMode = DISABLE; // on demand
ADC_InitStructure.ADC_ExternalTrigConv = ADC_ExternalTrigConv_T1_TRGO;
ADC_InitStructure.ADC_ExternalTrigConvEdge = ADC_ExternalTrigConvEdge_None;
ADC_InitStructure.ADC_DataAlign = ADC_DataAlign_Right; // 12 bit right aligned
ADC_InitStructure.ADC_ScanDirection = ADC_ScanDirection_Upward;
ADC_Init(ADC1, &ADC_InitStructure);
ADC_ChannelConfig(ADC1, ADC_Channel_4, ADC_SampleTime_13_5Cycles);
ADC_DiscModeCmd(ADC1, ENABLE);
// ADC calibration; but not used as returned value ends nowhere now...
ADC_GetCalibrationFactor(ADC1);
ADC_Cmd(ADC1, ENABLE);
// Probe on PA3+4
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_4;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AN;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_DOWN;
GPIO_Init(GPIOA, &GPIO_InitStructure);
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_3;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_Init(GPIOA, &GPIO_InitStructure);
// end of init code ...
int readADC(void) {
uint32_t temp = 0;
GPIOA->BSRR |= (GPIO_Pin_3); // Enable Sensor
// throw awaynfirstresult like on AVR? first value is wrong.
ADC_StartOfConversion(ADC1);
while(ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC) == RESET);
for (uint8_t i = 0; i<16; i++) { // oversampling
ADC_StartOfConversion(ADC1);
while(ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC) == RESET);
temp += ADC_GetConversionValue(ADC1);
}
GPIOA->BRR |= (GPIO_Pin_3); // Disable Sensor, save power
return (temp>>4);
}
I could also post a simple UART output for text feedback via terminal.
One issue remaining is that I can only use 13 IOs. Putting my LED to PF0 and PF1, adopting the code to initialize GPIOF + Clocks, ... nothing happens there. As you can see in the PLL / frequency init above, HSE is definatly disabled, in which case PF0 and PF1 should be usable as GPIO.
Maybe some voodoo is needed there.
-
I got my STM32's , but not the final PCB's yet.
I hacked a ghetto style print together on a tssop-28 board , complete w. 5v to 3v ldo , caps and a dual led.
I adapted this stm32F0 repos to fit the F030
https://github.com/szczys/stm32f0-discovery-basic-template
You have to adapt the linker file to fit the F30 (16k flash /4K ram) , and adjust the initial stakpointervalue
See Device/ldscripts/stm32f0discovery_def.ld , i have attached the modified one.
I also replaced the contents of src/main.c with the one from dannyf.
Bacically you run the following commands:
make clean
make all
make program
Or all in 1
make clean all program
And power off / on the STM32F030 board , now it blinks the led on PA0/PA1
Ohh i had to split the "reset halt" commands into separate lines or oocd would complain during programming.
in the extra/stm32f0-openocd.cfg command file
And the oocd board definition location th the makefile.
I can't attach the full project as it is 1MB+ zipped , but I have attached the files that i modified.
/Bingo
Edit:
I have a 100K pulldown on BOOT0 (you can see it) , and there's a 560R SMD's on the led pins
Edit2:
If using OOCD like i do - Save some time and remember to adjustCode: [Select]set WORKAREASIZE 0x1000= (4K ram) In the board definition file you are using.
I (the repos linked) was using stm32f0discovery.cfg witch has 8K Ram andCode: [Select]set WORKAREASIZE 0x2000,
and amazingly it worked for the test blinky , but when i switched to the current ST lib 1.3.1 it failed to program the flash every time.
-
Nice board, I like the idea with the LDO. The space on the TSSOP20-adapter is too limited for that.
I wonder why you needed to adopt the linker files. I use the generic stm32f0xx-ones which come with the Eclipse plug-ins / standard peripheral lib, they work flawless. -
Nice board, I like the idea with the LDO.
The space on the TSSOP20-adapter is too limited for that.
I wonder why you needed to adopt the linker files. I use the generic stm32f0xx-ones which come with the Eclipse plug-ins / standard peripheral lib, they work flawless.
If you use kapton on the back side , can't you squeeze a small LDO on there , like i did ??
The author made it for the F51 (discoveryF0) that has 8K ram , and one of the exported values are the initial stak , pointing at top 8K.
My F30 was NOT HAPPY with a SP initialized to "8K" , when i only have 4K ram.Code: [Select]/*
Linker subscript for STM32F051 definitions with 64K Flash and 8K RAM
Copyright RAISONANCE 2007
!!! This file is automatically generated by RIDE !!!
Do not modify it, as it will be erased at every link.
You can use, copy and distribute this file freely, but without any warranty.
*/
/* Memory Spaces Definitions */
ENTRY(Reset_Handler)
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 16K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 4K
}
/* highest address of the user mode stack */
_estack = 0x20001000;
_estack was 0x20002000; in the original ld file.
I always use makefiles , even when using Code::Blocks , and i haven't decided if i'm going to try out eclipse.
But anyways as i use makefiles and not the GUI "clicky-clicky" , i have to adapt those things for my self.
Not a problem when used to it.
But if you FSCK up' the stack , the MCU is going into "unknown orbit" somewhere , or maybe just HardFault
/Bingo -
Quote
How about pushing the frequency from 8 to 48 MHz
I would put some wait there and then at the end update SystemCoreClock - in case you use it in the rest of the code.
-
Quote
PF0 and PF1 should be usable as GPIO.
Forgot to mention this.
PF0/1 can be used as gpio pins only if HSE is disabled and clock is routed to it. You can disable HSE only via RCC_DeInit() or clearing the HSEON bit (bit 16).
So stepping through the code and watching the gpio registers and the RCC registers would be helpful.
-
The HSE is disabled via deinit(), and it doesn't matter where I put the line
RCC_HSEConfig(RCC_HSE_OFF);
- it doesn't help before or afer deinit(). I also modified CMSIS/stm32f0xx.c, there is some code for SysCLKinit where HSE gets set to on initially. That doesn't change anything. Stepping through the SystemInit with the debugger sounds reasonable. Would be the first time I find something with that
@bingo600: Ah, I didn't recognize it's EM:BLOCKS, I don't use that. I also have a 051-Disco but in Eclipse with that GNU-ARM extension stuff and CMSIS, STM-Standard peripheral lib, I get to choose the processor just by M0-class.
Don't know why, but mem.ld correctly has 18kb flash and 4kb ram in it. sections.ld only has absolute values for stack size min/max. To be honest, I didn't even look at it until now as it just worked well
Working with makefiles is great, but I like the comfort of having an auto complete with variables/function lookup and a nice overview of all files from the project and so on. It's more like a matter of taste. (I think the projects and includes are way too complex nowerdays to control them completely "by hand", thus I prefer a click-click-GUI.) -
Shoot!
I must have soldered something wrong on my "main testing board". Just took another one and it works as it should.
Sorry about this fuzz. Always use a multimeter and check your soldering/connections ... -
That's how we all learn,Quote
Always use a multimeter and check your soldering/connections
Just be a little bit cautious about that: the voltage on the +/- probes can exceed the maximum voltage those pins can take. Many times, a visual inspection (under a magnifying glass) is all it takes. -
Thanks for that tipp. I only measure with a "beeper" (continuity tester?) if there is a connection between the pin of the µC and the DIP-pin soldered, thus there is no current going into the µC.
As expected, PF1 had no connection - although there was plenty of solder which I needed to clean up first to produce no short.
Now it also works with my first prototype. I can only repeat again and again: This tiny bugger is just _awesome_. And so small!
Size comparison as attachment between stm32f103rb-, f103c8-, f103c8-like-leaflab-maple minimum boards, Arduino Pro Mini, Arduino Pro Micro and Arduino Nano. That tiny green thing is this board.
-
You used a ssop20 board? I used a ssop28 board - so mine is slightly bigger.
Yes, it is tiny. I think NXP had some bga Cortex-M parts too that are just as big as a grain of sand. -
Overclocking:
STM32F030 is spec'd to 48Mhz.
With flash latency 0: it runs to 52Mhz but craps out at 56Mhz;
With flash latency 1: it runs all the way to 64Mhz.
Not bad for something that's supposed to cost 30cents each.
-
Nice idea! Stable dimming, measuring and UART at 64 MHz:Code: [Select]
STM32F030-Test begins.
HCLK is 64 MHz, PCLK 64 MHz, System 64 MHz, ADC 14 MHz.
Temp: ~20 degrees C.
Temp: ~23 degrees C.
Temp: ~23 degrees C.
_But_ energy consumption increases significantly. With 48MHz, it drops to 0,13W and peaks at 0,27W.
With 64 MHz, it still peaks at 0,27W, but never drops below 0,22W.
(This is in combination with CH340G usb-2-serial adapter with a power LED as well.) -
It is so fast that it should be criminal,
-
I just noticed that CoIDE has updated its chip database to support F429/439 - no library support for those chips yet, however.
-
My parts list is still growing ...
Just read a bit about ferrite beads. Using a 10 µF capacitor next to the 100nF one is already great. Those ferrite beads are cheap in bigger volumes (100pcs SMD), so I ordered some and will use one on the VDDA pin for the connection to VDD. Should eliminate pretty much the rest of the noise - sources on the net write about the last 10% noise which is still there after using those two capacitors - and allow for more precise ADC readouts.
I'm looking forward to play around with those 1,6x0,8mm parts ...
-
Stepping through the next line, here is the output of our random number generator (32-bit):
0x077dbfbf (125681599).
Obviously, one would expect that each execution generates different numbers - hopefully,
-
Stepping through the code to examine variables and registers is a great way to debug the code.
However, if you need to output massive amount of data - like to output the random numbers for a test under diehard, you would need other ways, typically a usart module. You can capture the output there and export it to a text file to be processed later.
-
Since this thread is about someone going on the chip, we aren't going to pile on many modules here - or the code gets too out of hand.
It is a good time for you to learn to code in a modular fashion - the pieces of code posted here actually came from 4 - 5 separate modules (.h and .c files). They are co-mingled here for convenience and in a minimalist fashion.
I would encourage you to think of ways that are conducive to you to break up main.c into multiple modules. I can see a module handling clocks / chip initialization; a module handling gpio; a module handling adc1; a module handling random number generation;....
The code segments posted here are to provide the bare minimum functionality. However, they do serve to provide a basic function from which more functionality can be easily added: like set up an output in open drain; or an input with pull-up or pull-down; or the adc with scanning; or dma data transfer, etc.
The goal is so that next time, when you need those functionality, all you need is to copy those .h/.c modules to your project folder and link them into your project -> they are instantaneously available to you, and can be used with the confidence that they have been thoroughly debugged by you.
Writing a giant main.c is the surest sign of an overpaid programmer,
-
You may notice that the code is written so that it can be easily broken into modules.
Take this line for example:Code: [Select]#define ADCx ADC1 //adc1 module used
It is expecting that when you create your adc2 module, you can simply redefine ADCx to ADC2, and other changes, and the new adc2.c will recompile flawlessly.
When you attempt to break the code into modules, think about that.
-
Quote
typically a usart module.
Implementing a usart tx module on those chips is a breath. You need to implement three functions:
1) usart_init() to initialize the module to handle a certain baud rate, data length, stop bits, etc. It is executed once;
2) usart_puts() to transmit a string. You have two options here - use an interrupt or polling. For such a fast chip, it is a waste if it is not implemented through interrupt.
3) usart_busy() to tell if the module is busy. The trick here is to rely on the transmission buffer, not the transmission register.
-
As the code is developed on top of the ST standard peripheral library which has fairly good cross-platform compatability, porting the code to a different chip (F1/F3/F4 for example) is fairly easy.