Possible to program 3.2 from can?

Status
Not open for further replies.

bigboosted

Well-known member
I'm pretty new to arduino. I just discovered teensy a few days ago due to my latest tft project running to slow on nano. Also ran out of memory.

My first question is can my program include code that when a preset can message comes in it will enable the halfkay?
(I want to enbed a teensy and while I can leave a button avaliable it won't be easy to get to)

I read that something like this can be done. As long as the program doesn't crash.

My second question is there a way to upload a program to teensy via the can bus?

Thanks for the help. Sorry if this has been asked before but my search did not find much. I'll keep looking , but any direction would be much appreciated!

I've played with the arduino/nano and can sheild so I'm pretty fimiliar with how that works. I just ordered a teensy 3.2 and am looking forward to playing with the canflex.
 
Yeah, you can, actually... Just wire an i/o pin to the program pin, and toggle it low.
That will throw it in to programming mode as if you pressed the button :)
 
teensy can only be programmed via USB-HID
It can be placed into to-be-programed mode by

a) pressing button, or equivalently by connecting program pin to ground (e.g method suggested by xxajk)
b) by setting the USB-serial communication to a specific very low speed
c) by sending a specific USB-HID message
d) and from within program (as Frank indicates)

option a) works always (excluding very rare events that teensy got bricked, or intentionally locked by programmer)
options b) and c) work only if Teensy has running USB enabled, which implies that Teensy is not crashed. These options are typically use by different loaders.
 
You could write your own and run it from RAM.... This is something I've been sort of wanting to do myself.... program over serial an stuff like that.
 
You could write your own and run it from RAM.... This is something I've been sort of wanting to do myself.... program over serial an stuff like that.

How you get it into ram, except you have the bootloader part of your sketch, and obviously some bios?
 
You copy it from flash to a malloc'd arena and call it.
The trick is that the code must be position independent.
 
You copy it from flash to a malloc'd arena and call it.
The trick is that the code must be position independent.

OK, it is part of the sketch (indeed ALL sketches), now you need a way to receive from outside a command to activate bootloader. So there should be a comm-module (async?) be running reacting the go-to-bootloader command. Yes , I see the possibility.
 
You could have it as part of the beginning of the sketch... have a small wait in setup() looking for it to start, and if no start, just move on.
This would make it identical to arduino, and the reset pin/pad could even be wiggled with a capacitor on RTS line :)
 
Wow thanks for the fast responses!

Looks simple enough to get the halfkay running within the program!

Regarding the programing via can bus, I know anything is possible but what would it take? Pretty much a majorly modified bootloader?

It's something I would like to make happen but lack the skills as of now.

My ideal way would be a teensy programmer that's connected with USB to the pc. Then connected to the can bus.

On the bus would be one or more teensys connected that would only go into halfkay(or custom bootloader) mode when it's programmed code (specific can ID) is called on. Then the program sent via the can bus.

Sounds simple. But I know it's not.

Thanks again!
 
It doesn't have to be halfkay. It can be any protocol you want it to be, even something you invent.

Starting point: Look at eeprom.c on how to use flash, and run from RAM.
 
You could write your own and run it from RAM.... This is something I've been sort of wanting to do myself.... program over serial an stuff like that.

This should really only be attempted by experts, or by people who can afford the loss of a few boards due to "learning experiences". You can brick your Teensy if you do this incorrectly, particularly with writing wrong data to the flash config word.

The normal uploading process with Teensy Loader protects you from wrong config which can permanently brick your Teensy.

Starting point: Look at eeprom.c on how to use flash, and run from RAM.

Within that code, take notice of comments like this:

Code:
        // with great power comes great responsibility....
 
This should really only be attempted by experts, or by people who can afford the loss of a few boards due to "learning experiences". You can brick your Teensy if you do this incorrectly, particularly with writing wrong data to the flash config word.

The normal uploading process with Teensy Loader protects you from wrong config which can permanently brick your Teensy.

I've never been able to brick one myself, and I've done some pretty awful things like this. :)
Still, good idea/advice to observe caution.
 
An better approach might be to use the Kinetis-Bootloader and edit the teensyduino-linker-file to a higher-start address (to which jumps the Kinetis-bootloader).
I guess, the interrupt-table needs some attention, too. The flash-config-area is superflues in this case, and can be removed.
 
Last edited:
An better approach might be to use the Kinetis-Bootloader and edit the teensyduino-linker-file to a higher-start address (to which jumps the Kinetis-bootloader).
I guess, the interrupt-table needs some attention, too. The flash-config-area is superflues in this case, and can be removed.
You could do that...
As far as the isr vector table, that can be moved to RAM on a whim, and IIRC this already happens anyway, but I could be incorrect.
 
Yes, its copied from the flash from a fixed address (0 ?) But this is wrong, since in this case, it's the table that the Kinetis-loader uses.
 
Last edited:
Well, you could always write a sketch that does this, and load above it on the next sector, then execute.
 
Thanks for the replys! I'm pretty new to all this so most of your suggestions are above my current know how.

At this time I don't think I'm capable of even fully understanding the nano bootloader let alone the teensy.

So me trying to make a can bootloader won't happen.




So a few more questions if I can;

Is it possible to make a teensy program another teensy without the PC attached?

Program one teensy from the PC/IDE.

Remove it from the pc.

Hook it up serial to another teensy and power on both teensys and the one programs the other?

What I'm getting at is I think I could easily send a hex file over can. But I would need the receiving teensy to read and store that hex file. Then once commanded it could take that hex file and program another teensy with the hex file.

It would require 2 teensys at each can location.

I know there is a better way to do this but I'm trying to brainstorm a way I could make this happen with my limited skills.

Thanks again.
My Brain hurts now:)
 
I see NXP offers can bus bootloader for the DCS 56F83xx family. Any possible way to make this work for the Teensy?

Happened to come across it while searching around.
 
Why CAN? Is there anything else connected to the CAN bus, and if so, do you know what protocol to use for proper update procedure? Curious ...
 
Bigboosted, given a bootloader needs a whole bunch of hardware specific stuff you pretty much need something for your specific model (and sometimes revision) of CPU. If you are serious about a project you can update via canbus, work out the update process first and then sort out what interface that update will arrive by, since that part is pretty flexible. First you need a rock solid mechanism for managing the transition from one code set to another without bricking. How the code gets there is a far less substantial problem.
 
Status
Not open for further replies.
Back
Top