Author Topic: One Dollar One Minute ARM Development  (Read 135545 times)

0 Members and 1 Guest are viewing this topic.

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #125 on: September 12, 2014, 11:07:01 pm »
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 :-( )
« Last Edit: September 13, 2014, 12:46:34 am by westfw »
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #126 on: September 13, 2014, 12:49:03 pm »
Somebody offline requested more wiring information so I've added a photo of the bottom of the board in the second post. Also one showing a run/boot switch and reset button. Something like this is essential if you are interested in testing or modifying the simple LEDA9 program that I attached there last week or the hacked version of westfw files from a couple pages back.

Speaking of which, westfw, did your board come in? Everything working as expected? If so maybe put up a known good include/blinky pair for those who might be interested in more serious asm development than my crude demo.
 

Offline neslekkim

  • Super Contributor
  • ***
  • Posts: 1305
  • Country: no
Re: One Dollar One Minute ARM Development
« Reply #127 on: September 13, 2014, 06:10:46 pm »
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?
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #128 on: September 13, 2014, 08:55:10 pm »
Yes, good call. That certainly looks like a typo because, glancing at my breakout board, pin 47 must be ground not 3v or there would have been sparks on the dozens built so far. I'm sure westfw will be along to fix that. I'm also hoping what may be bugs in the latest blinky or include file can be updated. That would be very useful for anybody venturing beyond my dumb demo.

ps. Pin 48 with VCC looks correct. On my breakout board GND pins are on the outside and VCC pins on the inside which makes it very easy to build and check. The power pins are shorted inside the chip so double checking with a meter will show instantly if theres a miswire. Interestingly even though bypass caps seem to be optional these duplicate pins must all be wired together or the chip don't work.
« Last Edit: September 13, 2014, 09:06:41 pm by paulie »
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #129 on: September 13, 2014, 09:39:09 pm »
Quote
is 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.)

I see I have two "28" and no "29"; oops.

Is there a schematic or more detailed description of the board-level circuit somewhere?  Most of it is self-explanatory, but paulie said  "boot1 and boot0 markings are swapped on many of them", for example...

PS: My board that was supposed to arrive on thursday actually arrive today (Sat);  I have fixed the stm32flash utility from google code to compile on my Mac (have I mentioned that so far I've been using a Mac for all of this?), so I'll soon see if it works...

« Last Edit: September 13, 2014, 09:41:34 pm by westfw »
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #130 on: September 14, 2014, 11:32:59 am »
Quote
I'll soon see if it works...
I'm not having too much luck...
The bootloader should ALWAYS run when boot01 is 1/0, and it should run forever waiting for the proper serial comm, right?  My mac doesn't seem to be talking to the board at all, either via the stm32flash utility I found, or through a serial terminal emulator :-(  My PC seems to be able to talk to the board via the ST flash load demo "sometimes", and perhaps "most of the time" via putty. (note: same serial HW on both PC and Mac, and it seems to work fine in loopback or talking to another serial adapter.)  Sigh.
 

Offline neslekkim

  • Super Contributor
  • ***
  • Posts: 1305
  • Country: no
Re: One Dollar One Minute ARM Development
« Reply #131 on: September 14, 2014, 12:34:29 pm »
Quote
is 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 reason I asked, is that the board number in the spreadsheet, and the picture below, differs, on the picture it clearly states GND, and the spreadsheet says 3v3, so I wondered if the board are wrong, or the spreadsheet (there are known to be some boards comming from china that have errors.. )
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #132 on: September 14, 2014, 01:10:57 pm »
The bootloader should ALWAYS run when boot01 is 1/0, and it should run forever waiting for the proper serial comm, right?

Right. As of yesterday I've built nearly 100 of the DIY boards for myself and friends and although there's only one Ebay blue board in my collection I've poked at half dozen others. No flakyness so far. These things either worked or they didn't. When they didn't it always turned out to be something wrong with my wiring or procedures.

The only intermittent boot failures were long time ago with PIC and AVR and traced to bogus USB/serial. There are "issues" regarding hardware and drivers. I'm quite an expert on those (among other things. LOL) so suggest putting up a photo of yours, either from the original ad or snap one. Where did it come from? The $1 Ebay dealies with DTR are very reliable.

ps. All PC  for me, Win and Linux but no Mac.
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #133 on: September 14, 2014, 03:02:18 pm »
Somebody else on this end just had some problems so here's a couple more hints. As mentioned in the first post you MUST reset the chip before each download and make sure the "run user" box is checked. Some hints on the ST flash demo: set timeout for 1s. If it's not recognized by then somethings wrong. Also use 256kbaud which for some reason is more than 3x faster than 115k (6s vs 20s).
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #134 on: September 14, 2014, 10:17:23 pm »
Quote
There are "issues" regarding hardware and drivers.
Bingo!  Things work much better using my trusty FTDI cable.  I was trying to use on of those CA-42 phone cables (with a (probably counterfeit) Prolific chip) that were the state-of-the-art cheap usb-serial solution a couple of years ago.  I suspect that the chip/driver combination doesn't like the somewhat unusual 8bits plus Even parity configuration.

Update: Woo hoo!  I have blinking!

(huh.  One tends to look down on those arduino female connectors where everyone just plugs in wires and components.  But it's a PITA to stick female connectors on the end of LEDs (for example) so that they're easy to attach to these boards with male pins...)
« Last Edit: September 15, 2014, 02:13:41 am by westfw »
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #135 on: September 15, 2014, 05:43:49 am »
Code: [Select]
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 :-(
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: One Dollar One Minute ARM Development
« Reply #136 on: September 15, 2014, 08:14:23 am »
Code: [Select]
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 :-(
Did you set the target device correctly?
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #137 on: September 15, 2014, 09:08:46 am »
I have -mcpu=cortex-m3;  shouldn't that be enough?

 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: One Dollar One Minute ARM Development
« Reply #138 on: September 15, 2014, 09:50:07 am »
Quote
Woo hoo!  I have blinking!

Two weeks later, one of two "experienced programmers" eventually succeeded in blinking an led. The other one is still trying.

Phew!

Talk about steep learning curves, :)


================================
https://dannyelectronics.wordpress.com/
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2051
  • Country: nl
Re: One Dollar One Minute ARM Development
« Reply #139 on: September 15, 2014, 10:38:39 am »
Talk about steep learning curves, :)
Well, since the stated mission objective basically is the learning curve I'd say mission accomplished. The learning curve has been measured succesfully!

Not entirely sure about that "one minute" part though. At least it isn't "one man" anymore, thanks to westfw joining the fray. The "one dollar" probably still holds, not counting time obviously.

And as added benefit, it results in a confirmation of my personal bias. That being: "asm only on ARM? Nope not worth the hassle". Another thing that came out of it IMO, is that even to get a meaningful asm only development environment, you cannot escape using other tools to get there. That being you have to parse C include files to get useable asm defines and such. And you can do the parsing either by generating some C files, compile it, and process the output. Or do some perl/python/sed/awk/whatever scripting to get the job done. Not that I personally have any problem with having to parse C stuff in order to get to the asm only step, but it does take away the "purist asm" award.

Anyways, it will be interesting to see what the minimalist setup binary size is compared to the C equivalent.
And after that it will be interesting to see what the development time is for a moderate size application compared to C. Because spending a lot of time ONCE to get a known to work setup with really small binary size, I totally dig that. You spend your time once, and then you reuse your awesomely small setup in all your following projects. It's the time spent on the average application after that which is the thing...

Or maybe make an optimized minimal setup, and then you hand off control to the rest of the app written in C.

Anyways, keep it up! It makes for interesting reading.  :-+
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: One Dollar One Minute ARM Development
« Reply #140 on: September 15, 2014, 11:00:40 am »
I have -mcpu=cortex-m3;  shouldn't that be enough?
yeah should be enough I thought you might have selected generic ARM.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #141 on: September 15, 2014, 02:36:28 pm »
To be fair, most of the two weeks in my case was spent waiting for HW to arrive.
I could've gone to radioshack and picked up an arduino and spent the time (more than one minute) it takes to download the Arduino SW.  Or for that matter, it would have been a very slow internet connection not to have been able to download "more than just the assembler" in the time I spent soldering (even though I got a pre-assembled board, and only soldered up several adapter cables.  (one of which didn't work.))
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #142 on: September 15, 2014, 03:07:45 pm »
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 :-(

Adding ".n" pseudo-op will force short addressing as shown in the first two examples below.

Also note that, as mentioned early in this thread, using "=cortex-m3" CL option does not result in the same binary as ".thumb" directive. I discovered this right after you introduced me to the latter. Various combinations of CL options and source directives can produce quite varied output. Functionally similar but... Compare binary generated for NOP and address length of branch.

Code: [Select]
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>

Code: [Select]
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>

Code: [Select]
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>

Code: [Select]
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>

Code: [Select]
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>

One (one with open mind anyway) can learn a lot from little experiments like this. Another thing I can't understand, or forgive in this case, is the objdump LST output being incompatible with the assembler. For example our beloved ';' comment characters which are sprinkled throughout. Kinda like the ST bootloader failing to restore reset defaults before running user.

Software engineers, can't live with 'em, can't shoot 'em. Well you could but then what would internet hotshots argue about?
« Last Edit: September 15, 2014, 04:10:14 pm by paulie »
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #143 on: September 16, 2014, 01:02:35 am »
Initializing the clock for 72MHz, controlled by the external crystal:
Code: [Select]

/*
 * 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.))

(I keep or-ing bits into my registers, and forgetting to store them back to the peripheral. HLL habits.)

(Is it working?  I dunno.  It blinks faster than it used to.  It doesn't look 9x faster, though.  I'm not sure how those wait states end up affecting the timing of the simple blink loop.  Next step; SysTick.)

 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #144 on: September 16, 2014, 01:43:51 am »
observation: The .asmh isn't as much use as it might be, because most of the C examples use the peripheral library calls instead of the stm32f10x.h level structures and register values.  So you can't simply translate most of the existing C examples into asm; you have to either dig through the peripheral library source, or go all the way back to the datasheet.

Got out the scope, increased the frequency, and did some measuring.   With the clock configuration code in, the pin is only toggling at about 4x the rate with the internal 8MHz clock... ???

 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #145 on: September 16, 2014, 10:39:08 am »
Your program compiled and ran just as expected on my blue board. At least once the LED was moved to the right pin. That new MYBIT did throw me for a loop (haha... you got me!). Commenting the 2 calls also caused it to run slower pretty much the same as you described. I tried to make it compatible with the hardware on page one by changing MYBIT to 9 and CRL to CRH but no go. Looks like I'll have to do a little disassembly to see what I missed.

I gotta say that code is just about the best tutorial on ARM assembly published on the net so far. I would love to put that up at the beginning of the thread to help the unwashed masses. First I need to get that bit moved and it would be nice to figure out why the clock is not running exactly as expected. In any case thanks for that and hopefully you won't give up.

I wish my UART experiments were going as well. Looks like divisor issues. I was hoping to avoid it but maybe it will be necessary to get involved with that clock stuff after all.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: One Dollar One Minute ARM Development
« Reply #146 on: September 16, 2014, 11:00:15 am »
Quote
Is it working?  I dunno.

Follow the datasheet; If that's too difficult, follow the library; If that is even too difficult, follow the SetSysClock() in the system_xxx.c -> that's the closest example.

Quote
the unwashed masses.

With your demonstrated skills and experience, it is probably unjustified to call people that way. Be humble.

Quote
Looks like divisor issues.

Probably more than that.

Quote
most of the C examples use the peripheral library calls instead of the stm32f10x.h level structures and register values.

most of them rely on the base address and register struct established in stm32f10x.h. The register values are generally replaced by enums in the peripheral library and the bit values are generally not used.
================================
https://dannyelectronics.wordpress.com/
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #147 on: September 16, 2014, 05:46:00 pm »
Quote
Quote
Is it working?  I dunno.
Follow the datasheet
Oh, my code  does something.  What I mean is that I am having trouble figuring out how fast my delay loop should run if I increase the clock rate from 32 Mhz to 72Mhz, when that also means adding two wait-states to the flash controller, AND the "prefetch buffer" is turned on, AND I have the ARM pipeline to contend with as well.  (technically, you're not supposed to run 32MHz, 0-wait states.  But that did seem to work.  Unlike 72MHz @ 0 WS, which I also ended up trying accidentally.)  So I don't know for sure whether the processor is actually running at 72MHz and is slowed down by WS and code structure, or whether I have some mistake that is causing it to run a a different clock rate than I expect.  (Different PLL multipliers are just changes of a constant, and I'm definitely multiplying by SOMETHING, so it's difficult to imagine what would cause a different clock rate than expected...

I should probably import the max-rate pin toggle code from that other thread and do some real measurements...

Quote
follow the library
Oh, I am.  More or less.  The library code is "deep."  Pretty much for every assembly language statement I have in my clock init function, the library function (setSysClockTo72()) has one or more function calls, frequently with parameters that don't match exactly with the stm32f10x.h symbols.  I hope a lot of that gets inlined and optimized away because things are constants.   (Could you post disassembled setSysClockTo72() code, since you have a C/plib environment handy?)  They also explicitly set a lot of bits/fields to the default poweron values, while my code is assuming that it's starting with poweron values.  (it looks like the plib would allow you do do things like:
Code: [Select]
setSysClockTo72();  // run fast.
 toggletest();
 setSysClockToHSE();  // basic crystal rate
 toggletest();
 setSysClockTo48();  // intermediate speed
 toggletest();

I have to say that what the peripheral library documentation may lack in clarity, it makes up for with excellent cross-reference links to the actual source code.  Browsing through the library with a CHM browser is ... pretty nice.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: One Dollar One Minute ARM Development
« Reply #148 on: September 16, 2014, 07:10:48 pm »
If I were you, I would increase the speed to 24Mhz, WS0. Measure the blinking frequency; and then 24Mhz, WS1, measure the blinking frequency again. I can tell from my own experience, flash ws has a bigger impact on the execution speed.

If you look at the SystemInit() or the library, you will see lots of looping around for the oscillators / PLL to be ready. That's one area where a mistake could have been made.

You can check if you look at the RCC registers, particularly the pre/after multipliers to be sure that you are running at 72Mhz.

SetSystenClock() is in the system_xxxx.c file.
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: One Dollar One Minute ARM Development
« Reply #149 on: September 16, 2014, 07:12:10 pm »
Quote
it makes up for with excellent cross-reference links to the actual source code.

The use of doxygen helps. But more important than that is the availability of "go to definition" of your IDE. It is a life saver.
================================
https://dannyelectronics.wordpress.com/
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf