Hi,
I have an existing design that uses an integrated Teensy 3.2 module. It's also an open-source design, and so it relies on stock upstream firmware.
Recently, for space-saving and ease-of-assembly reasons, I decided to try eliminating the Teensy module and putting a MK20DX256 chip and it's supporting circuitry onto the main PCB directly.
Since this application doesn't require end-user USB connectivity, I omitted the Teensy bootloader (MKL02) chip and connected the appropriate pins to a JTAG header.
On my first completed assemblies of this board, I have no problem erasing and flashing hex files onto the main MK20DX256 chip. However, the program does not seem to actually execute on the chip after it has been successfully flashed and verified. I've spent several hours troubleshooting this, but I haven't identified the problem yet.
My question is this: Is it reasonable for me to expect a binary (hex) that was compiled for a Teensy 3.2 target to run on a blank MK20DX256 without a connected MKL02 (running the Teensy bootloader), or is this notion fundamentally flawed? Basically, I'm trying to figure out if the problem is a mistake in my design or assembly, or if the current behavior (non-functioning) is actually the expected behavior. I noticed some warnings about pin PTA4 in regards to NMI issues with blank chips, and I was wondering if this could be part of the issue? My design does not use this pin, and the physical pin is disconnected (floating).
I also want to note that my intent is not to cut Paul (PJRC) out of the loop here. If the ultimate answer is to integrate the MKL02 chip and a USB port, and use the Teensy loader to program the boards (instead of a J-Link), then I'll do that without hesitation. Software (code) modification is not an option in this case.
Thanks very much in advance for any insight. I'm also happy to provide any additional details if necessary.
Best,
Dan
I have an existing design that uses an integrated Teensy 3.2 module. It's also an open-source design, and so it relies on stock upstream firmware.
Recently, for space-saving and ease-of-assembly reasons, I decided to try eliminating the Teensy module and putting a MK20DX256 chip and it's supporting circuitry onto the main PCB directly.
Since this application doesn't require end-user USB connectivity, I omitted the Teensy bootloader (MKL02) chip and connected the appropriate pins to a JTAG header.
On my first completed assemblies of this board, I have no problem erasing and flashing hex files onto the main MK20DX256 chip. However, the program does not seem to actually execute on the chip after it has been successfully flashed and verified. I've spent several hours troubleshooting this, but I haven't identified the problem yet.
My question is this: Is it reasonable for me to expect a binary (hex) that was compiled for a Teensy 3.2 target to run on a blank MK20DX256 without a connected MKL02 (running the Teensy bootloader), or is this notion fundamentally flawed? Basically, I'm trying to figure out if the problem is a mistake in my design or assembly, or if the current behavior (non-functioning) is actually the expected behavior. I noticed some warnings about pin PTA4 in regards to NMI issues with blank chips, and I was wondering if this could be part of the issue? My design does not use this pin, and the physical pin is disconnected (floating).
I also want to note that my intent is not to cut Paul (PJRC) out of the loop here. If the ultimate answer is to integrate the MKL02 chip and a USB port, and use the Teensy loader to program the boards (instead of a J-Link), then I'll do that without hesitation. Software (code) modification is not an option in this case.
Thanks very much in advance for any insight. I'm also happy to provide any additional details if necessary.
Best,
Dan
