I'll tell the whole story in case somebody thinks I don't need the boot loader.
I wrote an assembly level program on the Teensy-2 and compiled it using Atmel Studio-7. The video I used as a guide said to include the assembler directive ".ORG $0", but I didn't do that because I feared it might write my program from memory address 0, overwriting the boot loader. With or without the directive, I think that's what has happened.
I downloaded the program to the Teensy in the fond belief that the boot loader would be protected somehow (by fuses), and would not be overwritten. I now believe that was a poor assumption, as my Teensy appears to be bricked. The program I wrote sends an easily verifyable pattern to the LED - a varying mark-space signal that goes from (1 period ON, 255 periods OFF) to (255 periods ON, 1 period OFF), then (always ON), so that the LED comes on at zero brightness and brightens up to full intensity over a 1.5 second period. The eventual application was to be a soft start for an electric motor.
I don't know the internals of the Teensy, but most processors I have previously worked with are only capable of one thing when switched on. They execute the instruction at memory location zero. If it is not a jump, they continue with the instructions in sequential addresses. As I said, I don't know how the Teensy works, so please correct me if my surmise is wrong :
* It starts off by executing a part of the boot loader that tests to see if the button is depressed, and if not, will jump to the user program.
* If the button is pressed, it causes a reset that takes operation back to address-0, then, as the button is still pressed, it goes into the boot loader functionality.
My belief is that, even though I omitted the assembler directive ".ORG $0", the assembler caused the program to start from memory address 0, and has consequently overwritten the boot loader, which means I can no longer communicate with the host-based loader, so I can't transfer software to it.
The symptoms are that when the Teensy is plugged in, it runs my program as shown by the LED.
If I press the button, it re-starts my program instead of communicating with the host-based loader.
If I disconnect it, and hold the button while reconnecting it, my program runs as soon as it is released. There doesn't seem to be a boot loder any more.
Bye bye Teensy.
I think the way to overcome this on my next Teensy will be to compile my program behind the loader. Is the loader available as assembler source code? If so, can you tell ,me where to find it? Then I can compile the boot loader (starting from addr-0) with my program behind it.
Incidentally, a peculiar thing happened that I can't explain - can anybody offer an explanation? My program is supposed to bring the LED on very dimly (brightness = 0) and bring it up to full brightness, but that doesn't happen. It does start at zero, but comes up to about half brightness, so I thought my program was only reaching 50% mark-space ratio. I put a meter on it, which showed near-enough 2.5V, but it's a digital meter with a slow reaction, so I got my scope out and looked. The mark-space performs exactly as it should, going from 0% to 100% in the correct time period, but with a signal that varies between 0V and 2.5V. I don't understand why it isn't 0V-5V. I checked the 5V and found it to be correct. Any thoughts? Here's the program
I wrote an assembly level program on the Teensy-2 and compiled it using Atmel Studio-7. The video I used as a guide said to include the assembler directive ".ORG $0", but I didn't do that because I feared it might write my program from memory address 0, overwriting the boot loader. With or without the directive, I think that's what has happened.
I downloaded the program to the Teensy in the fond belief that the boot loader would be protected somehow (by fuses), and would not be overwritten. I now believe that was a poor assumption, as my Teensy appears to be bricked. The program I wrote sends an easily verifyable pattern to the LED - a varying mark-space signal that goes from (1 period ON, 255 periods OFF) to (255 periods ON, 1 period OFF), then (always ON), so that the LED comes on at zero brightness and brightens up to full intensity over a 1.5 second period. The eventual application was to be a soft start for an electric motor.
I don't know the internals of the Teensy, but most processors I have previously worked with are only capable of one thing when switched on. They execute the instruction at memory location zero. If it is not a jump, they continue with the instructions in sequential addresses. As I said, I don't know how the Teensy works, so please correct me if my surmise is wrong :
* It starts off by executing a part of the boot loader that tests to see if the button is depressed, and if not, will jump to the user program.
* If the button is pressed, it causes a reset that takes operation back to address-0, then, as the button is still pressed, it goes into the boot loader functionality.
My belief is that, even though I omitted the assembler directive ".ORG $0", the assembler caused the program to start from memory address 0, and has consequently overwritten the boot loader, which means I can no longer communicate with the host-based loader, so I can't transfer software to it.
The symptoms are that when the Teensy is plugged in, it runs my program as shown by the LED.
If I press the button, it re-starts my program instead of communicating with the host-based loader.
If I disconnect it, and hold the button while reconnecting it, my program runs as soon as it is released. There doesn't seem to be a boot loder any more.
Bye bye Teensy.
I think the way to overcome this on my next Teensy will be to compile my program behind the loader. Is the loader available as assembler source code? If so, can you tell ,me where to find it? Then I can compile the boot loader (starting from addr-0) with my program behind it.
Incidentally, a peculiar thing happened that I can't explain - can anybody offer an explanation? My program is supposed to bring the LED on very dimly (brightness = 0) and bring it up to full brightness, but that doesn't happen. It does start at zero, but comes up to about half brightness, so I thought my program was only reaching 50% mark-space ratio. I put a meter on it, which showed near-enough 2.5V, but it's a digital meter with a slow reaction, so I got my scope out and looked. The mark-space performs exactly as it should, going from 0% to 100% in the correct time period, but with a signal that varies between 0V and 2.5V. I don't understand why it isn't 0V-5V. I checked the 5V and found it to be correct. Any thoughts? Here's the program
HTML:
.INCLUDE "m32u4def.inc" ; target uController
; Set the stack pointer to 0x0AFF
LDI R16,0x0a
OUT SPH, R16
LDI R16, 0xff
OUT SPL, R16
LDI R16,165 ; R16 = 171
LDI R17,0 ; R17 = 255
wait_a_sec: RCALL DelayLoop
DEC R17
BRNE wait_a_sec ; branches back 255 times, then drops through on zero
DEC R16
BRNE wait_a_sec ; branches back on non-zero, then drops through after 1 sec (approx)
LDI R21,1 ; LED on timer
LDI R22,255 ; LED off timer
LDI R23,0x40 ; pin D6 high
LDI R24,0 ; pin D6 low
loop1: MOV R17,R22 ; R17<-(0)
OUT PORTD,R24 ; Set pin low
wait_lo: RCALL DelayLoop ; delay 182 clocks
dec R17 ; R2 dec to 255, 254, 253...2, 1, 0
BRNE wait_lo ; wait for R2 to count down to zero
MOV R16,R21 ; R16<-(1)
OUT PORTD,R23 ; Set PD6 high (LED on) [Pin 26 on chip - Bottom RH pin on board with USB to top]
wait_hi: RCALL DelayLoop ; delay 182 clocks
dec R16
BRNE wait_hi ; wait for R1 to count down to zero
INC R21
DEC R22
BRNE loop1
; idle loop, leaving portD6 high.
wait_here: JMP wait_here - end of operation
DelayLoop: LDI R25,61 ; 1
Dloop: DEC R25 ; 1 (3) [93]
BRNE Dloop ; 1 [89]
RET
.EXIT
