TeensyTransfer

Ah ok, my fault :)

All device that are used must be enabled/initialized here. In a former version, this was not needed (tt did it).

But, great that we found the problem, finally..!
 
Works for me AGAIN - FINALLY (four days later) with that line uncommented . . . it used to just work by default . . . and unsupported interfaces should give feedback.

Maybe trigger a compile line NOTE like when 'Raw_HID' isn't chosen that desired devices must be indicated when compiling:
#if !defined(TTRANSFER_DEVICES) // ALWAYS print this - FASTLED does one like this saying the version #
#Warning only: Be sure to enable ParallelFlash or SerialFlash.begin in the sketch if they are supported
#endif
Click to expand...
 
Other option might be to simply have a couple example programs:
SerialFlashTeensyTransfer
ParallelFlashTeensyTransfer
...
 
I just put the SerialFlash enabled sketch on a raw Teensy with no flash and it failed better than not having it on during compile!

Perhaps just don't comment out the SerialFlash.begin(FlashChipSelect); code and have the code handle the errors? After all it is : "serflash (default)" { and it was initially this way }

It does give bogus info for "-i" and "-l" - but that can be ignored or possibly detected in the code: "serflash not found on #'FlashChipSelect'"::
C:\tCode\libraries\TeensyTransfer\extras\teensytransfer>teensytransfer.exe -l serflash

C:\tCode\libraries\TeensyTransfer\extras\teensytransfer>teensytransfer.exe -i serflash
ID : 00 00 00
Serial: 00 00 00 00 00 00 00 00
Size : 1048576 Bytes

C:\tCode\libraries\TeensyTransfer\extras\teensytransfer>teensytransfer.exe -i parflash
teensytransfer: Communication error

C:\tCode\libraries\TeensyTransfer\extras\teensytransfer>teensytransfer.exe -l parflash
teensytransfer: Communication error

C:\tCode\libraries\TeensyTransfer\extras\teensytransfer>teensytransfer.exe -i teensy
Model : Teensy 3.1/3.2 (MK20DX256)
Serial: 46703
MAC : 04:E9:E5:00:B6:6F
EEPROM: 2048 Bytes
F_CPU : 96000000 Hz
F_PLL : 96000000 Hz
F_BUS : 48000000 Hz
F_MEM : 24000000 Hz
Click to expand...

Of course I don't have the ParallelFlash library so the same thing doesn't work there as it won't compile. But specifying the param results in Comm error above, However that is not fatal like it is was BEFORE with SerialFlash , I can then go on to issue other commands successfully after that Comm Error - when done with SerialFlash not compiled in it somehow corrupts the sketch.
 
Last edited:
Another note - glanced at the code - here is why PARFLASH fails differently I suppose ... so the sketch would need to say - edit library as well to get _HAVE_PARFLASH

#define _HAVE_SERFLASH //Serial Flash
//#define _HAVE_PARFLASH //Parallel Flash

I commented "#define _HAVE_SERFLASH" and even when RA_HID the code fails compile on multiple 'RAW_HID' required when _HAVE_SERFLASH is not defined, somewhere it isn't nested right?
 
The code does not fail to compile, if you have the ParallelFlash Library installed.
But this makes only sense if you have the hardware to use it. Currently, there is no hardware...only the "alpha" displayboard. As far as i know, there is only one existing displayboard with parallel flash (better "parallel connected spi flash"): My own :)
A second (not tested) has FMS.


Edit: The "Communication error".. well, it is ok in this case. The user should have a minimum of info which hardware he uses.. currently, i tend not change this behavior. Or, feel free to make a pullrequest :) It is on Github because it is "open source".
Edit: ParFlash is a special case... it will not be a problem.
 
Last edited:
Good work Frank - just looking to get it to be user friendly to build/use - which is tough to make perfect given it is a library with hardware & code dependencies.

I have 2 messages above - not sure reading the reply p#56 - of course it will compile with the library - I wasn't bug'ging that. As noted I see the #ifdef in the library and I suppose that explains why the parflash fails more gracefully - with the case statements gone - it isn't trying to call any code like serflash.

In the case I got stuck on for days - I had the hardware - and the comm error prevented any other code from working after that - as we discovered because of the commented SerialFlash.begin. So rather than returning true error it was crashing something it seems.

p#55: It will fail to compile if you remove the serflash ifdef in the library even as RAW_HID - something odd there as it pops up multiple times not just once and done. Should show if you try it. Without serflash the sketch compiles - then the failure is in the library code - but even with RAW_HID on it wouldn't compile - that was the odd part.
 
Last edited:
Ah..i see now what you mean..thanks.
Can you fix it ?

Edit. There is a "#include <Arduino.h>" missing (for that case).
 
Last edited:
Yes "include Arduino.h" allows it to compile without serflash #define - and it works for "-I Teensy" - and then the communications errors are not fatal. Not that you should disable the "//#define _HAVE_SERFLASH" - but it will work if done.

I don't see why that works - but it does.

Does "void SerialFlashChip::readID()" ever return '0s on a valid/working flash chip? If not could that be checked (once before any other calls inTeensyTransfer::transfer()) to give a better error when compiled for serflash and no serflash 'working' hardware was present? Returning an error might help a user understand they have an issue.
 
Hi Tim,
no, it does not return '0s with a working flash chip. But..hm.. i'm not sure what you mean. Zeroes can have different reasons - missing hardware, failing hardware, not initialized library.. (more?)
I decided to keep it simple and to print "Communication error" if "something" does not work. But i'm open for better solutions.. ! (Perhaps as pullrequest ;-) )
 
Last edited:
Frank: I got as far as the code below - it won't call any serflash function if no ID can be read.

This of course is just proof of concept - to work right you'd need to replace "serflash_info();" with a new function that sent back a valid HID message that the TeensyTransfer.exe would understand as an error message: sendHIDerror( device, mode, ERR_NO_SERFLASH );

You could use this new sendHIDerror() function on any error so that some HID messages don't go unanswered (that seems to get the HID stack out of sync), or you don't just assume commErr(), and you can alert the user to the nature of the problem? That does really add code all over though - rather than a (0==rawhid_rcv) you could get a valid message to look if it said ERROR_???, then change to commErr( ERROR_??? ) return a custom message.

Code: 
void TeensyTransfer::transfer(void) {
  uint8_t device, mode;
  int n;
	n = RawHID.recv(buffer, 0); // 0 timeout = do not wait
	if (n<1) return;

	mode = buffer[0];
	device = buffer[1];
	if ( hid_sendAck() < 0 ) {
		//Serial.printf("timeout\n");
		return;
	}

	switch (device) {
#ifdef _HAVE_SERFLASH
		case 0 : {				
[B]				uint8_t buff[8];
				SerialFlash.readID(&buff[0]);
				if ( 0 == (buff[0] + buff[1] + buff[2] ) ) {[U]serflash_info();[/U]return;}
[/B]				switch (mode) {
 
I see what you mean.. hm, perhaps i can create a new command "checkAccess" (like "ready" some lines below) - this way it would be compatible to the existing executables, too.
I'm a bit reluctant, because i always need help to to make the MAC-executable - perhaps i try to install the apple-gcc on my lubuntu, first. i need it anyway.
 
Last edited:
Yeah - that would break prior versions - along with the 'add code all over'. If I see what you mean :: checkAccess() hid_msg returning a copy of a "static Last_Error" kept in the sketch structure after any error?

Perhaps calling checkAccess() within commErr() would make a clean and easy change?

Code: 
void commErr() {
	if ( checkAccess() ) 
	{
	 	// Add custom error messages 
	}
	else
		die("Communication error");
}

Also perhaps embed a 'Version #' in checkAccess() send and rcv in case you can use that or the rest of the HID message in future versions and call it anytime the EXE needs to talk to the INO.

In testing two Teensy's here - one with serflash and one without it became apparent that HID just finds the first device (like Teensy.exe and not TYQT). So maybe the checkAccess() should always include the Teensy SER# so you can identify when you end up talking to a different Teensy.
 
I've added a bunch of new HEX-Files for all Teensy 3.x models + variants for AudioShield (different SPI-Configuration).

For details, pls. see Post #2

The precompiled hexfiles for T3.6 are configured to F_CPU = 120MHz to prevent EEPROM-problems.
 
Last edited:
Frank B said:
...
The precompiled hexfiles for T3.6 are configured to F_CPU = 120MHz to prevent EEPROM-problems.
Click to expand...

Frank any chance you tried testing with a T_3.6 at full speed and my EEprom edits to see it work? I'm hoping to get enough real world use test cases where it usefully works in the event Paul doesn't have an alternate solution at hand. Seeing MichaelM use it for the Prop Shield 9DOF calibration writes was good.
 
FWIW, I recompiled Teensy transfer (I'm running on a Fedora 22 system), and the new one does work, though I did find it would go off into the woods after awhile, particularly during long transfers. I'm loading up Halloween sounds, and the longest was 3.1 megabyte Monster Mash in .mp3 format. The best way seemed to be restarting the Teensy after each download.

Now to update my Arduino-Teensy-Codec libraries.
 
I think, i don't support this tool for a long time.. I hope we have a better way to fill the flash in a few month..
 
defragster said:
Frank any chance you tried testing with a T_3.6 at full speed and my EEprom edits to see it work? I'm hoping to get enough real world use test cases where it usefully works in the event Paul doesn't have an alternate solution at hand. Seeing MichaelM use it for the Prop Shield 9DOF calibration writes was good.
Click to expand...

Hm, there is no use of more speed. So, no i did not try it - but - why should it NOT work ? It worked in all tests so far ! :cool: Good work !
 
Indeed it should work - but knowing it did before Paul has to decide on how to allow HSRUN EEPROM writes would make me feel better. And it won't actually run much faster - though my testing did show that there is some odd slowness in some write methods at 120 MHz. In your case I assume the HID data transfer is the slow point - and it is only 4KB.
 
MichaelMeissner said:
FWIW, I recompiled Teensy transfer (I'm running on a Fedora 22 system), and the new one does work, though I did find it would go off into the woods after awhile, particularly during long transfers. I'm loading up Halloween sounds, and the longest was 3.1 megabyte Monster Mash in .mp3 format. The best way seemed to be restarting the Teensy after each download.

Now to update my Arduino-Teensy-Codec libraries.
Click to expand...

Hi Michael,
i've fixed some bugs - could you please try the new version ?
I'd like to know wether it works better for you .. :)

Thank you !
 
Frank B said:
Hi Michael,
i've fixed some bugs - could you please try the new version ?
I'd like to know wether it works better for you .. :)

Thank you !
Click to expand...
Ok, I'll try it after work.

Have you updated the mp3 files (play_sd_mp3)? I tried to use them on the Teensy 3.6, and I didn't get anything (and it came back quicker than it should have)? I do recall getting the message about having two SD libraries, so it may have picked the wrong one and is trying to access the micro SD card on the 3.6, rather than the flash memory.
 
You must log in or register to reply here.
Back
Top