For a project I want to use the Teensy 3.1 board (see “Hacking the Teensy V3.1 for SWD Debugging“) in USB CDC mode: that way the Teensy board can connect to the host and exchange data or attach a console to the Teensy board: that way I can connect the Teensy over USB to the host use the USB as communication interface:
I’m using the Teensy in a ‘non-standard’ way: I’m debugging it with a SWD debug probe so I have complete control over the hardware. See “Hacking the Teensy V3.1 for SWD Debugging“:
I have published a KDS V2.0.0 project on GitHub here:
https://github.com/ErichStyger/mcuoneclipse/tree/master/Examples/KDS/Teensy_3.1/Teensy3.1_CDC
If you want to create such a project yourself (e.g. with Kinetis Design Studio, using V2.0.0), here are the steps:
- Make sure you have the latest components from SourceForge (see “McuOnEclipse Releases on SourceForge“)
- Create a new project (File > New > Kinetis Design Project) for the MK20DX256xxx7 72 MHz) microcontroller:
- Configure the CPU clocks to use the 16 MHz external crystal and PEE mode:
- MCG settings are for PEE and 96 MHzPLL output clock:
- Configure the core clocks. Important part is to use the PLL clock selection and that it shows 96 MHz at the bottom:
- Add the FSL_USB_Stack component to the project:
- Use Init_USB_OTG_VAR0 for initialization and set device class to CDC Device:
- In the Init component, enable the clock and configure it for 48 MHz using thePLL/FLL clock:
- Specify the CPU in the CDC device component:
- Configure the Rx andTx ring buffers: Use an appropriate buffer size for both (e.g. 64 bytes). Do this both for Rx andTx:
With this, everything is configured. Generate Code with Processor Expert, and you can add your application code. The following is a bare metal example which waits until the USB device has been enumerated, then it communicates over USB CDC with the host:
static uint8_t cdc_buffer[USB1_DATA_BUFF_SIZE]; static uint8_t in_buffer[USB1_DATA_BUFF_SIZE]; static void CDC_Run(void) { int i, cnt = 0; uint32_t val = 0; unsigned char buf[16]; for(;;) { while(CDC1_App_Task(cdc_buffer, sizeof(cdc_buffer))==ERR_BUSOFF) { /* device not enumerated */ LED1_Neg(); WAIT1_Waitms(10); } if (CDC1_GetCharsInRxBuf()!=0) { i = 0; while( i<sizeof(in_buffer)-1 && CDC1_GetChar(&in_buffer[i])==ERR_OK ) { i++; } in_buffer[i] = '\0'; (void)CDC1_SendString((unsigned char*)"echo: "); (void)CDC1_SendString(in_buffer); UTIL1_strcpy(buf, sizeof(buf), (unsigned char*)"val: "); UTIL1_strcatNum32u(buf, sizeof(buf), val); UTIL1_strcat(buf, sizeof(buf), (unsigned char*)"\r\n"); (void)CDC1_SendString(buf); val++; LED1_Neg(); } else { WAIT1_Waitms(10); cnt++; if ((cnt%128)==0) { LED1_Neg(); } if ((cnt%1024)==0) { /* from time to time, write some text */ (void)CDC1_SendString((unsigned char*)"Type some text and it will echo.\r\n"); CDC1_SendBlock((unsigned char*)"hello?\r\n", sizeof("hello?\r\n")-1); } } } }
Happy Teensing 🙂
Eric
I have done this with 3 x UART bridges: http://www.utasker.com/kinetis/TEENSY_3.1.html#CDC3
on the Teensy 3.1 and also the Teensy LC http://www.utasker.com/kinetis/TEENSY_LC.html
For that work I didn’t use a debugger but instead simulated the Kinetis so that debugging was not necessary on the HW (so no SWD required),
However, since you have a debugger hooked up I am wondering whether you can throw some light on what may be a problem with the Mini54 programmer that the board has?
The subject is discussed here towards the end of the thread:
https://forum.pjrc.com/threads/27457-Need-hel-pwith-a-bootloader
It is “suspected” that there is a probem with the loader if the chip is secured (0x40c = 0xff) and that the Mini54 can’t recover from it – causing the board to become “bricked” although it is not really so.
I don’t dare do the test on my single board since I don’t want to have to build a programmer to recover, if it is the case.
Do you therefore have the possibility to command a mass-erase of the chip and see whether the original programmer can handle that state? As you known, your debugger will simply say that it is secured and unsecure it and so you have no risk. It would help clear up a potential issue that could be causing aparently “bricked” Teensys to be lost.
Thanks
Mark
LikeLike
Hi Mark,
I would need to try this probably with a new/different board, as mine with the cut traces is not very easy to repair the traces again.
The Mini54 programmer probably does not handle all the different cases, and therefore it does not properly handle the ‘secure’ state of the device with a mass erase.
Erich
LikeLike
Eric
I will make a copy in “Hacking the Teensy V3.1 for SWD Debugging“ because I have seen that some people have used the reset line to isolate the Mini54 and maybe someone who uses the Teensy often with it will be willing to do the experiment (rather than you needing to modify another board).
Regards
Mark
LikeLike
Pingback: Proof of Concept: Open Source ARM SWD Debug and General Purpose Board | MCU on Eclipse