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

0 Members and 2 Guests are viewing this topic.

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #50 on: September 05, 2014, 02:22:38 pm »
Success! Those scripts were used a lot in my C projects but never paid much attention to. Anyway just copied the ld file from one of my C directories over then added -T to the cmd line and it worked like a charm. Thanks, Between you and Westf I may have a chance at getting this right after all.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: One Dollar One Minute ARM Development
« Reply #51 on: September 05, 2014, 04:52:18 pm »
It is very difficult to imagine that a beginner starts on those chips in assembly.

To work on a reasonable project on those chips in assembly, you have to be an expert or you have tons of resources (time+money).
================================
https://dannyelectronics.wordpress.com/
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #52 on: September 06, 2014, 01:47:02 am »
$1 is a bit misleading.  You're talking about spending ~$10 for enough stuff to make 10 boards.  Plus at least a USB/Serial cable to connect it to something.   Which is only subtly different, I guess, but still...  (this is not dissimilar from my very first arduino-related purchase.  10 bare board, 5 chips, and an FTDI cable from MDC.  And the fact that I COULD do that was pretty instrumental in my ever becoming involved with Arduino.)

I've ordered some STM32f103c8t6 hardware.  $10 for a pre-built single board shipped from closer than China.  It feels a bit funny, since I already have several ARM-based development boards lying around, but in view of arguments I've already made about the prices, I can hardly complain that it's too much money to spend on an interesting experiment.

Quote
It is very difficult to imagine that a beginner starts on those chips in assembly.
I agree entirely.  Assembly is "not used" in the ARM world.  The chip documentation does not include assembly examples, and community software is not written in assembler (and there's no symbol files for asm, aside from what that nut posted here...)   What assembly you CAN find uses the official ARM syntax, which I've mentioned is not the same as the Gnu assembler syntax.

That said, I think the concept of providing a "reduced" toolset has a lot of validity to it.  A "1-minute download" is unnecessary, but it would be nice not to have to go searching all over the internet for the various pieces needed to get started, an not wind up with a "choose processor" menu containing hundreds of chips.

I wonder if something based on the Arduino download would be a good starting point.  It's already got win/linux/mac versions of a complete compiler toolchain, and its about a 200MB download (even with the complete AVR toolset as well.)
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #53 on: September 06, 2014, 06:14:41 am »
Well, this is crap:
Code: [Select]
#define  GPIO_CRL_MODE3                      ((uint32_t)0x00003000)        /*!< MODE3[1:0] bits (Port x mode bits, pin 3) */
#define  GPIO_CRL_MODE3_0                    ((uint32_t)0x00001000)        /*!< Bit 0 */
#define  GPIO_CRL_MODE3_1                    ((uint32_t)0x00002000)        /*!< Bit 1 */
    :
#define  GPIO_CRL_CNF3                       ((uint32_t)0x0000C000)        /*!< CNF3[1:0] bits (Port x configuration bits, pin 3) */
#define  GPIO_CRL_CNF3_0                     ((uint32_t)0x00004000)        /*!< Bit 0 */
#define  GPIO_CRL_CNF3_1                     ((uint32_t)0x00008000)        /*!< Bit 1 */
Thank you SO much for giving me a bunch of long and meaningless names to refer to the bits used to configure the GPIO ports.  They must REALLY want people to use their peripheral library instead of "bare metal."  Unfortunately, it looks like the peripheral library is pretty questionable as well:
Code: [Select]
#define IS_GPIO_PIN(PIN) ((((PIN) & (uint16_t)0x00) == 0x00) && ((PIN) != (uint16_t)0x00))(I guess it's a good thing that no one actually turns ON those "assert" checks?)

grr...

Edit: I guess it's not quite as bad as I thought, but it doesn't inspire confidence, either...

« Last Edit: September 06, 2014, 06:39:09 am by westfw »
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #54 on: September 06, 2014, 03:41:01 pm »
To work on a reasonable project on those chips in assembly, you have to be an expert

Or crazy. Pretty much everyone agrees C is the way to go there but for a quick start to test hardware and getting an understanding of how a chip really works I think ASM can't be beat.  IMO your comment about resources seems way off base. If I'm not mistaken this thread is the first and only time 100% functional tools for creating a program have actually been attached and not just linked.  Many will not even have the courtesy to do that.

And one or two bucks for working hardware is "tons of money"? Hmmmm... Also note that last night I won a bet with a buddy by downloading then creating and verifying a program in less than 40 seconds. True I'm very familiar with the steps involved (hit 'a') but this was phone line internet!

This don't look like "tons of resources (time + money)"  from my viewpoint.

BTW The GCC file in first post has been updated with STM32.ld. That demo program seems to behave just as expected stepping through with GDB/OOCD now.
« Last Edit: September 06, 2014, 03:50:57 pm by paulie »
 

Offline leppie

  • Frequent Contributor
  • **
  • Posts: 269
  • Country: za
Re: One Dollar One Minute ARM Development
« Reply #55 on: September 06, 2014, 04:06:14 pm »
The STM32 Nucloe range is pretty impressive at just over $10 a pop. http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847

Compared to an Arduino you get a lot more.
 

Online zapta

  • Super Contributor
  • ***
  • Posts: 6189
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #56 on: September 06, 2014, 04:45:25 pm »
The STM32 Nucloe range is pretty impressive at just over $10 a pop. http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847

Compared to an Arduino you get a lot more.

Does it come with a single package install IDE that runs on all three major OS's.  ?

It's the overall package that counts.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #57 on: September 06, 2014, 09:35:42 pm »
Quote
[for]getting an understanding of how a chip really works I think ASM can't be beat.
Oh, I think you'll get a pretty good understanding of things trying to code in C without libc to back you up :-)

I think what makes this project interesting is that we're learning DIFFERENT things than you learn by throwing up the vendor or hobbyist toolset and coding away with the provided libraries and IDE.  It's an excercise in what tools actually do what, and which ones are needed, and in how crappy (or not) the define files are, and in what's actually happening under the hood of an IDE when you click the "build" button.  (for example, I was SHOCKED that xxx-gcc.exe is about the same size as as xxx-as.exe.  Even supposing that there is a separate xxx-cpp to handle C preprocesing (also "about the same size"), I had still assumed that the C compiler itself would be bigger...  And ah hah!  cc1.exe is out there in the lib directory; apparently not considered a user executable and thus not in the bin directory.  (and yes, it's pretty huge.)
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: One Dollar One Minute ARM Development
« Reply #58 on: September 06, 2014, 09:45:57 pm »
IMHO it would serve many people well if they spend some time on how the build process actually works. Unfortunately they don't even teach that in schools/universities.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline leppie

  • Frequent Contributor
  • **
  • Posts: 269
  • Country: za
Re: One Dollar One Minute ARM Development
« Reply #59 on: September 06, 2014, 09:52:16 pm »
Does it come with a single package install IDE that runs on all three major OS's.  ?

It's the overall package that counts.

It support MBED, and normal embedded IDE's. So I would say yes.
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2051
  • Country: nl
Re: One Dollar One Minute ARM Development
« Reply #60 on: September 06, 2014, 10:25:30 pm »
It's the overall package that counts.
It comes with a free "How to put together your own toolchain" lesson that will serve you well for the rest of your life.

That said, sometimes an easy starting point is nice to have as well. Just so you have a known to work situation, and then you branch out to from that to put together the dev environment you really need. Or you pay $$$ to buy something that is just that. Or is almost that, but not quite. Nothing is ever free. Either you flush time, or you flush money.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #61 on: September 06, 2014, 11:14:20 pm »
New .asmh file added in https://www.eevblog.com/forum/microcontrollers/one-dollar-one-minute-arm-development/msg507400/#msg507400

My source code now looks like:

Code: [Select]
.include "stm32f103c8.asmh"
.syntax unified


@ BLINK in ARM Assembler
@ For ST32F103c8t6, perhaps
@ Aug 2014, by Bill Westfield - released to Public Domain.
@
 .equ STACKSIZE, 1024
 .equ HEAPSIZE, 8192

        .globl  __Vectors
Vectors: .word    SRAM_BASE+HEAPSIZE+STACKSIZE @ Top of Stack
.word   __start + 1            @ Reset Handler

@ The program itself.

.equ myport, GPIOA_BASE @ must be portA...
.equ mybit, 6 @ arbitrary bit choice, for now.

_start:
.globl  _start
__start:
ldr r0, =RCC_APB2ENR
ldr r1, [r0] @ old val
orr r1, r1, #RCC_APB2ENR_IOPAEN @@ enable PORTA clk
str r1, [r0]
nop @ Wait for PORTF to get clocked.

initf: mov r1, #((GPIO_MODE_OUT+GPIO_CNF_PP) << (mybit*4))  @@ output bits
ldr r0, =GPIOA_BASE @ GPIO_PORTF
str r1, [r0, #GPIO_CRL_O]  @ set bit to output
mov r2, #(1<<mybit)    @
loop: ldr r1, [r0, #GPIO_ODR_O] @ read DATA reg
eor r1, r2          @ complement bit
str r1, [r0, #GPIO_ODR_O] @ write

mov r1, #(4*1024*1024) @ Delay count

delay: subs r1, r1, #1 @ decrement
bne delay
b loop

.end
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #62 on: September 06, 2014, 11:47:29 pm »
I think what makes this project interesting is that we're learning DIFFERENT things than you learn by throwing up the vendor or hobbyist toolset and coding away with the provided libraries and IDE.

Definitely. I've been building controllers with this chip for almost a year but  in the last 48 hours of this thread have picked up more information (and inspiration) than all that time. Several failed attempts involving IAR demo and some other Eclipse based packages did little to arouse my interest. I felt like part of the Human Centipede with first guy connected to the last, recycling the same waste endlessly. It wasnt until starting to play with the inner workings of GCC things got really exciting.

BTW I just tried your program with the new include and got something about RCC-APB2ENR in delay undefined. Have you tried this on real hardware? Did your F103 board arrive yet?

I cant' wait to see how this turns out.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #63 on: September 07, 2014, 05:07:06 am »
Quote
I just tried your program with the new include and got something about RCC-APB2ENR in delay undefined. Have you tried this on real hardware? Did your F103 board arrive yet?

Ahh.  It turns out I wasn't running my output through the linker.  The as command produced an a.out file, and I assumed that it was done (sort of like the way the c compiler works.)  But apparently not...  I'll upload a new file.

I'm expecting the hardware next week; I only paid extra to get it shipped from the US instead of China, not for "expedited shipping."

 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #64 on: September 07, 2014, 06:09:57 am »
(new asmh uploaded.)

The thing is...  I spent the first six years or so of my career programming almost exclusively in assembly language.  The OS and all the system utilities were written in assembly language, because that was How Things Were Done, on that particular system at that particular time.  And there was a WONDERFUL macro assembler, and a huge set of standardized macros for defining and using higher-level language concepts (structures, local variables, stack frames, looping and conditional code structures..)  And there was a relatively large set of programmers working on similar stuff who would discuss such things.  And the machine language was elegant and cool...  It was great!

If you're coming from an 8-bit microchip PIC environment, you've seen some of this sort of thing (minus the elegant machine language :-))

But ARM doesn't have any of that, as far as I can tell.   It has an assembler designed to assemble code output by a C compiler, and a machine language designed to be used by compilers and efficient to implement in hardware.  And everyone programs it in C.  Writing in assembly language for such a chip is ... ill fated (like the song: "kinda like construction work, with a toothpick for a tool.)
 
The following users thanked this post: elecdonia

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #65 on: September 07, 2014, 09:54:10 am »
everyone programs it in C

Not true. There's you and me, so at least two now. Maybe three if you count that fellow in Nyurba. LOL
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #66 on: September 07, 2014, 10:07:41 am »
Sorry; I program ARMs in C.  I think it's interesting to contemplate some basic programming in asm, and I'm certainly willing to LOOK at the asm produced by the compiler (which seems to be a rare thing; people think they need to be an expert at the asm to learn something by looking at the compiler output.  they're wrong...)  But I have no real interest in actually writing any full programs in ARM asm.  Just the occasional optimization, subroutine, or "educational exercise."
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #67 on: September 07, 2014, 10:29:04 am »
Ok, so there's just me and maybe that guy in Russia. I'm determined to write something in ASM that works if it kills me. Even if it's just to flash a LED or send a character. Almost everything I've picked up so far comes from reading the list file. After poking a CRLF and fudging the RCC to quell the errors here's what AS thinks you want to do:

Code: [Select]
08000008 <_start>:
 8000008: e59f0038 ldr r0, [pc, #56] ; 8000048 <delay+0xc>
 800000c: e5901000 ldr r1, [r0]
 8000010: e3811004 orr r1, r1, #4
 8000014: e5801000 str r1, [r0]
 8000018: e1a00000 nop ; (mov r0, r0)

0800001c <initf>:
 800001c: e3a01401 mov r1, #16777216 ; 0x1000000
 8000020: e59f0024 ldr r0, [pc, #36] ; 800004c <delay+0x10>
 8000024: e5801000 str r1, [r0]
 8000028: e3a02040 mov r2, #64 ; 0x40

0800002c <loop>:
 800002c: e590100c ldr r1, [r0, #12]
 8000030: e0211002 eor r1, r1, r2
 8000034: e580100c str r1, [r0, #12]
 8000038: e3a01501 mov r1, #4194304 ; 0x400000

0800003c <delay>:
 800003c: e2511001 subs r1, r1, #1
 8000040: 1afffffd bne 800003c <delay>
 8000044: eafffff8 b 800002c <loop>
 8000048: 00001234 andeq r1, r0, r4, lsr r2
 800004c: 40010800 andmi r0, r1, r0, lsl #16

I'll admit it don't make a lot of sense to me ATM. Particularly those load stores. My own version to flash an LED isn't quite there yet either. I'm beginning to think it may actually take me more than 3 instructions to do it but we shall see.

ps. What does the "=" mean in your operands? I see it appends data to the binary but why?

It's also surprising you abandoned the ".thumb" directive. Was that intentional?
« Last Edit: September 07, 2014, 11:03:30 am by paulie »
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #68 on: September 07, 2014, 12:13:16 pm »
Good news. I've finally got that damn LED to flash. It didn't take 3 instructions as predicted. Only 2! This is great. Now to see if a character can be sent out via UART. I'm not going to worry about baud rate for now. Just get anything to squirt out then maybe adjust clock to get it right as a next step.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #69 on: September 07, 2014, 08:41:44 pm »
Quote
Code: [Select]
08000008 <_start>:
 8000008: e59f0038 ldr r0, [pc, #56] ; 8000048 <delay+0xc>
 800000c: e5901000 ldr r1, [r0]
 8000010: e3811004 orr r1, r1, #4
 8000014: e5801000 str r1, [r0]
 8000018: e1a00000 nop ; (mov r0, r0)
That's interesting.  You're getting 32bit instructions.  Oh, I think I see.  I had removed the .thumb directive, because it seemed to be doing the same thing as the -mcpu=cortex-m3 option in my compile line, but you probably aren't using that option...

Quote
What does the "=" mean in your operands? I see it appends data to the binary but why?
The ARM doesn't have a "load from 32bit address" instruction, nor an instruction to load an arbitrary 32bit constant intro a register.   (presumably because those would make instructions 64bits long, screw up the pipeline, and stuff like that.)
Every load instruction has an index register, and a relatively small offset (<4096) from that index register.
So the usual way to access a peripheral register is to load its address into an index register, and then access it via the index register.
And the usual way to load a 32bit address into an index register is to stick that constant in memory "near" the code that needs it, and access it by indexing off of the PC register.  The "=constant" assembler structure  sets that up for you; plunks the constant in nearby code space and sets up a pc-indexed instruction to access it.

Interestingly (?) MIPS code on PIC32 has similar limitations on constants, but the compiler produces sequences like "move the high 16bits of the constant into the high 16bits of the register, OR the register with the low 16bits of of the constant."
« Last Edit: September 07, 2014, 08:47:48 pm by westfw »
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #70 on: September 08, 2014, 01:28:22 pm »
Thanks for that explanation. I was aware of the difficulty loading 32bit immediates but wasn't up to speed on '=' symbol so was using a rather crude method. Now my own LED program is much cleaner.

Regarding the .thumb issue the source directive does behave slightly different  than command line option.  NOP actually comes out NOP (bf00) with the latter but mov r8,r8 (46c0) with the former. Don't really matter I guess but interesting.

BTW to compensate for the missing .equiv in your .asmh file, in order to stop the undefined error message I added the following line to your version:

.equ RCC_APB2ENR,0x40021000

ps. It compiles ok now. I had some trouble failing to reset at first but it blinks fine. Congratulations, I was proud of myself for managing to turn on the LED but looks like you are the first person to ever actually continuous blink in assembly.
« Last Edit: September 08, 2014, 01:38:39 pm by paulie »
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #71 on: September 08, 2014, 03:33:23 pm »
Well, days ago, for a different ARM, different assembler: https://www.eevblog.com/forum/microcontrollers/stm32-ghetto-style/msg503594/#msg503594

I've decided that I REALLY dislike "@" as a comment character.

Here's the code with "homework" style comments:

Code: [Select]
/*
 * BLINK in ARM Assembler
 * For ST32F103c8t6, perhaps
 * Aug 2014, by Bill Westfield - released to Public Domain.
 */

.include "stm32f103c8.asmh"
.syntax unified
.thumb

/*
 * Options settable by the user.
 */
.equ STACKSIZE, 1024
.equ HEAPSIZE, 8192
.equ myport, GPIOA_BASE /* must be portA... */
.equ mybit, 6 /* arbitrary bit choice, for now. */

/*
 * The ARM needs at least two words at the start of the flash that
 * specify the initial stack pointer and the reset start address.
 */

        .globl  _Vectors
_Vectors: .word    SRAM_BASE+HEAPSIZE+STACKSIZE /* Top of Stack */
.word   _start + 1            /* Reset Handler (thumb!) */

.globl  _start
_start:
/*
 * In order to use the GPIO ports, you first have to enable
 * a clock to that port.  This is done through the "Reset and
 * Clock Control (RCC) structure, but there are random different
 * registers/bits depending on which bus has the peripheral.
 *
 *  C equivalient: myClkCtrlReg |= myClkEnaBit;
 */
ldr r0, =RCC_APB2ENR
ldr r1, [r0] /* old val */
orr r1, r1, #RCC_APB2ENR_IOPAEN /* enable PORTA clk */
str r1, [r0]

/*
 * Now set up the GPIO pin for output.  Each pin is controlled
 * by 4 bits in the CRL or CRH register (depending on bit)
 *
 *  C equivalient: mygpio.CRx = MYGPIOMODE<<(myBitPos);
 */
initf: mov r1, #((GPIO_MODE_OUT+GPIO_CNF_PP) << (mybit*4))  /* output bits */
ldr r0, =GPIOA_BASE /* GPIO_PORTF */
str r1, [r0, #GPIO_CRL_O]  /* set bit to output */

/*
 * Now loop around and toggle the GPIO pin.
 * While the port has atomic set/reset ports, I'm going to just
 * do a non-atom read and xor.
 *
 *  C equivalient: while (1) { mygpio.ODR ^= 1<<mybit ; }
 */
mov r2, #(1<<mybit)    /* put the bit mask in a register */
loop: ldr r1, [r0, #GPIO_ODR_O] /* read DATA reg */
eor r1, r2          /* complement bit */
str r1, [r0, #GPIO_ODR_O] /* write */

/*
 * Delay loop.  I pick a constant that's a power of two so that
 * a single instruction with a shifted 8bit constant will be used.
 *
 *  C equivalient: for (uint32_t i=4096*1024; i != 0; i--) {}
 */
mov r1, #(4*1024*1024) /* Delay count */
delay:   subs r1, #1 /* decrement */
  bne delay

b loop

.end
 

Offline timb

  • Super Contributor
  • ***
  • Posts: 2536
  • Country: us
  • Pretentiously Posting Polysyllabic Prose
    • timb.us
Re: One Dollar One Minute ARM Development
« Reply #72 on: September 08, 2014, 04:08:37 pm »

The download section is hidden in the fine print and when you get there is no binary for Mac OSX.

Ahem ... Cough..Cough  :-//

https://launchpad.net/gcc-arm-embedded/+download

And the Mac version
https://launchpad.net/gcc-arm-embedded/4.8/4.8-2014-q2-update/+download/gcc-arm-none-eabi-4_8-2014q2-20140609-mac.tar.bz2


/Bingo

1 What main page link did you use to get to that download page?

2 tar? bz2? This is not the common way to deliver precompiled Mac binaries (see the exe for windows)

Uh, Tarball files are a very, very common way of delivering development tools on the Mac. Since OS X is running a delicious chewy *NIX core, the built-in Archive utility will de-compress them just fine straight through Finder.

This is not some GUI based development tool. You have to use it through the command line anyway, so why would you expect them to package it in a DMG?


Sent from my Smartphone
Any sufficiently advanced technology is indistinguishable from magic; e.g., Cheez Whiz, Hot Dogs and RF.
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #73 on: September 08, 2014, 11:32:31 pm »
I've decided that I REALLY dislike "@" as a comment character.

I also dislike that queer '@' but the C convention '/*...*/' strikes me as a big pain in the ass too so it's C++ '//' for me. What's even stranger is the disassembler uses ';'. There are other issues that cause LST code to not compile. Not a good thing for GCC or any other assembler IMO.

Anyway we have a problem Houston. These routines blink fine when run from the bootloader but fail miserably on reset or power up. I've attached a file for your program called noblink.hex and one for one that doesn't misbehave in this way, blink.hex (PB3). WTF. It looks like it should work but we are missing something. Maybe hw faults so full blown vector table is required. That is one difference compared to the working one. Maybe the bootloader is failing to enter with reset defaults (BAD bootloader!). It's not register dependency lost on power down because simple reset acts the same. One of the Ebay blue boards is being used for these latest tests to minimize chance of hardware incompatibilities but same thing with the DIY. IDK.
« Last Edit: September 08, 2014, 11:45:30 pm by paulie »
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #74 on: September 08, 2014, 11:52:32 pm »
Quote
we are missing something.
Probably some sort of necessary clock initialization.  The TI tiva i've been playing with has some reasonable defaults and just runs things slowly if you haven't done anything, but it wouldn't be unusual for there to be more...
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf