Spreadsheet of board/chip pinout, for the $7 board variants we've been talking about:
https://docs.google.com/spreadsheet/ccc?key=0AqdMB5dovDUZdGR6cVprUnkwTV9CMUNybV9VMjF5a0E&usp=sharing
(No hardware yet :-( )
is pin 47-48 marked wrong on the board?
I'll soon see if it works...
Quoteis pin 47-48 marked wrong on the board?The "board" pin numbers do not match up with the chip pin numbers, and are just arbitrary. Probably not "right", because I'm not aware of a standard for quad in-line "packages." (that's one reason I added the annotated photo.)
The bootloader should ALWAYS run when boot01 is 1/0, and it should run forever waiting for the proper serial comm, right?
There are "issues" regarding hardware and drivers.
08000036 <delay>:
8000036: 3901 subs r1, #1
8000038: f47f affd bne.w 8000036 <delay>
800003c: f7ff bff5 b.w 800002a <loop>
I can't figure out why it's generating "long" branches. My Keil assembler example puts each of those branches into a single 16bit instruction. I can't find any relevant switches, directives, or instruction variants that look like they'd change the behavior :-(Code: [Select]08000036 <delay>:
I can't figure out why it's generating "long" branches. My Keil assembler example puts each of those branches into a single 16bit instruction. I can't find any relevant switches, directives, or instruction variants that look like they'd change the behavior :-(
8000036: 3901 subs r1, #1
8000038: f47f affd bne.w 8000036 <delay>
800003c: f7ff bff5 b.w 800002a <loop>
Woo hoo! I have blinking!
Talk about steep learning curves,
I have -mcpu=cortex-m3; shouldn't that be enough?
I can't figure out why it's generating "long" branches.
I can't find any relevant switches, directives, or instruction variants that look like they'd change the behavior :-(
arm-none-eabi-as -mcpu=cortex-m3 -o t.o t.s
with:
.thumb
.syntax unified
nop
start:
b.n start
begat:
08000000 <start-0x2>:
8000000: bf00 nop
08000002 <start>:
8000002: e7fe b.n 8000002 <start>
arm-none-eabi-as -mcpu=cortex-m3 -o t.o t.s
with:
.thumb
.syntax unified
nop
start:
b start
begat:
08000000 <start-0x2>:
8000000: bf00 nop
08000002 <start>:
8000002: f7ff bffe b.w 8000002 <start>
arm-none-eabi-as -o t.o t.s
with:
.thumb
.syntax unified
nop
start:
b start
begat:
08000000 <start-0x2>:
8000000: 46c0 nop ; (mov r8, r8)
08000002 <start>:
8000002: f7ff bffe b.w 8000002 <start>
arm-none-eabi-as -mcpu=cortex-m3 -o t.o t.s
with:
.thumb
.syntax unified
nop
start:
b .
begat:
08000000 <start-0x2>:
8000000: bf00 nop
08000002 <start>:
8000002: e7fe b.n 8000002 <start>
arm-none-eabi-as -o t.o t.s
with:
.thumb
.syntax unified
nop
start:
b .
begat:
08000000 <start-0x2>:
8000000: 46c0 nop ; (mov r8, r8)
08000002 <start>:
8000002: e7fe b.n 8000002 <start>
/*
* Initialize the clock to our max speed (72MHz), assuming an external 8MHz crystal.
* This also involves configuring the flash for wait states, and dividing the APB1
* (low speed peripheral bus) clock.
*/
ClockInit:
/*
* Set the flash for 2 wait states - the max needed at 72MHz.
* (do this FIRST!)
*/
ldr r0, =FLASH_R_BASE /* Flash control register */
ldr r1, [r0, #FLASH_ACR]
orr r1, #FLASH_ACR_LATENCY_2 /* Set for two wait states */
str r1, [r0, #FLASH_ACR]
/*
* Enable the oscillator for the external crystal, and wait
* for it to finish starting up.
*/
ldr r0, =RCC_BASE /* Clock control registers*/
ldr r1, [r0, #RCC_CR] /* get control reg contents */
orr r1, #RCC_CR_HSEON /* Turn on crystal oscillator */
str r1, [r0, #RCC_CR]
clklp: ldr r1, [r0, #RCC_CR]
tst r1, #RCC_CR_HSERDY /* wait for clock ready */
beq.n clklp
/*
* Configure and enable the PLL,then start it and wait for lock.
*/
ldr r1, [r0, #RCC_CFGR] /* Get clock config register */
orr r1, #RCC_CFGR_PLLMULL9 + RCC_CFGR_PLLSRC_HSE /* Multiply osc by 9 */
orr r1, #RCC_CFGR_PPRE1_DIV2 /* But make sure APB1 is < 36MHz */
str r1, [r0, #RCC_CFGR]
ldr r1, [r0, #RCC_CR] /* get control reg contents */
orr r1, #RCC_CR_PLLON /* Turn on PLL */
str r1, [r0, #RCC_CR] /* store */
plllp: ldr r1, [r0, #RCC_CR]
tst r1, #RCC_CR_PLLRDY /* wait for clock ready */
beq.n plllp
/*
* Select the PLL output as our system clock
*/
ldr r1, [r0, #RCC_CFGR]
orr r1, #RCC_CFGR_SW_PLL /* Select PLL */
str r1, [r0, #RCC_CFGR]
bx lr /* Return */
What a pain in the neck - a perfect example of the sort of low-level grunt-work on uninteresting peripherals that an embedded programmer would rather not waste time figuring out. (The standard peripheral library code that does this looks like it would expand to "really big." It's got abstractions piled on top of abstractions, properly sets/clears the state of nearly every bit (even if you "know" the startup state) (and pretty much one bit/field at a time.))Is it working? I dunno.
the unwashed masses.
Looks like divisor issues.
most of the C examples use the peripheral library calls instead of the stm32f10x.h level structures and register values.
QuoteIs it working? I dunno.Follow the datasheet
follow the library
setSysClockTo72(); // run fast.
toggletest();
setSysClockToHSE(); // basic crystal rate
toggletest();
setSysClockTo48(); // intermediate speed
toggletest();
it makes up for with excellent cross-reference links to the actual source code.