Using TD1.62B3 with Dev Board 4 or 5

wwatson

wwatson

Well-known member
TD 1.62 beta 3 is working with Devboard 4 & 5 devices. I have tested 8080 parallel displays and several other devices with success.
The following is the repo README.md instructions for installation found here.
Code: 
1. Install arduino-1.8.19 and then install TD1.62B3.
2. Download this repo and install it the "Arduino" folder. It will then look like "Arduino/hardware".
3. From "arduino-1.8.19/hardware", copy the tools folder to "Arduino/hardware".
4. Change to directory "Arduino/hardware/Files_In_This_Folder_Are_Copied_To_cores_teensy4".
5. Copy the three files in the above directory to "arduino-1.8.19-TD1.62B3/hardware/teensy/avr/cores/teensy4".
6. The three modified files,"core_pins.h", "digital.c" and "pwm.c", will overwrite the existing files.So make sure you back them up.
All that was changed in the three files was the extention of pin numbers defined and processed (pins 55 to 69).

Arduino IDE 2.3.9 compiles but fails to upload to Devboard with this error: "Platform 'Teensy:avr' not found".
I'm not smart enough to know why :unsure:
Really did not spend much time looking for the reason why. Have not tried setting up and testing with W11 yet. That's next...
 
Thanks for the heads up. I kdiffed it and found I am missing some padconfig's for pins 40 yo 54. I took the repo off the market for now. I will add in the missing pad configs. This brings up the question about padconfigs for pins 55 to 69? I don't think they were defined before...
 
Let's talk of the required voltage for the 500 MHz part industrial temperature parts.

In 1.61 we're using 1.175 volts at 528 MHz. In prior versions we were using 1.150 volts.

NXP's datasheet for industrial products says the range is 1.15 to 1.26. At least as I understand this, NXP is saying 1.150 volts is enough for the entire wide temperature range.

We're now at 1.175 volts. Is that not enough?

1780616707537.png
 
It can run at that voltage... but it will also fault if stressed appropriately. The formula I used that never saw any random faults was 1.15V for anything over 24MHz plus 0.025V for every 25MHz multiple above 432MHz, e.g. for 528MHz:
1.15 + floor((528 - 432) / 25) * 0.025 = 1.225V
 
Last edited:
Curious. Have we seen any issues, faults or failures in any of the industrial devices with any of the voltage or speed settings? I know the settings can affect the lifetime of the device as well as power consumption and heat generation...
Code: 
Applying the maximum voltage results in maximum power consumption and heat generation. NXP recommends a voltage set
point = (Vmin + the supply tolerance). This result in an optimized power/speed ratio.
 
wwatson said:
Curious. Have we seen any issues, faults or failures in any of the industrial devices with any of the voltage or speed settings? I know the settings can affect the lifetime of the device as well as power consumption and heat generation...
Click to expand...
There's at least two methods I know of that are likely to trigger random faults that seem to be due to brown-outs / power issues: very heavy usage of FLASHMEM functions, or high rate of interrupts with WFI instructions in between.
 
I really need to see a test case which reproduce the problem. This formula is far beyond what NXP says is needed, getting close to the maximum specified voltage at 528 MHz, where NXP recommends using the minimum specified voltage to reduce heat.

I've already added 25mV above what NXP says is needed, applied between 460 to 528 MHz. I hope you can understand when it comes to the default settings we ship in the software to everyone, this sort of extraordinary claim needs to be backed up by substantial evidence.

However, I might add a separate function in the core library which lets anyone increase the CPU voltage without changing the clock speed. Anyone could also publish this as a library, since it's just hardware registers that are writable. If some highly demanding applications really do need an increase, hopefully having a library or special function would let those projects meet their needs, and maybe we could encourage people who use it to give feedback.

But to make the default for everyone higher than we have now (which is 25 mV above what NXP says is needed), reproducible test cases are needed to unquestionably demonstrate the need to increase everyone's power consumption.
 
Given that this may be detrimental to the life the Teensy I would recommend that it is NOT part of a library ( that would make it too easy to apply ) but a method on how to achieve it should be CLEARLY documented.
i.e. make it available but not too easy. The user MUST explicitly want to make the changes.
 
PaulStoffregen said:
test case which reproduce the problem.
Click to expand...
This. Then maybe it could be part of any Voltage change code to determine when it may be appropriate.

The Industrial part on the @Dogbone06 boards doing memory tests to the SDRAM (using altered PSRAM test) is where it was observed on those boards as standard voltage gave failures that went away with elevated voltage at the time on those boards.

And Stock T_4.1's on another thread running at 528 MHz were somewhere around 50% repro across a number of boards. So, it seems it was PCB or 1062 silicon dependent where the functional failure could be observed.
 
@defragster - That was the answer I was looking for. I remembered that there was something that was affected by the lower voltage. So that meens the SDRAM IF is the only thing that needed the higher voltage setting?

I also found a possible issue in the core_pins.h file at the digitalWriteFast() function around line #1878:
Code: 
            } else if (pin == 39) {
                CORE_PIN39_PORTSET = CORE_PIN39_BITMASK;
#if CORE_NUM_DIGITAL > 40 <------------ "> 40" would be 41 and up.
            } else if (pin == 40) { <---------------- which means this if statement is always false and pin 40 is never used here.
                CORE_PIN40_PORTSET = CORE_PIN40_BITMASK;

This is found in the digitalWriteFast() function which contains several more instances of this possible issue...
EDIT: digitalReadFast() as well.
EDIT2: Found same issue in "digital.c" starting at line #94 and #102.
 
Last edited:
wwatson said:
TD 1.62 beta 3 is working with Devboard 4 & 5 devices. I have tested 8080 parallel displays and several other devices with success.
The following is the repo README.md instructions for installation found here.
Code: 
1. Install arduino-1.8.19 and then install TD1.62B3.
2. Download this repo and install it the "Arduino" folder. It will then look like "Arduino/hardware".
3. From "arduino-1.8.19/hardware", copy the tools folder to "Arduino/hardware".
4. Change to directory "Arduino/hardware/Files_In_This_Folder_Are_Copied_To_cores_teensy4".
5. Copy the three files in the above directory to "arduino-1.8.19-TD1.62B3/hardware/teensy/avr/cores/teensy4".
6. The three modified files,"core_pins.h", "digital.c" and "pwm.c", will overwrite the existing files.So make sure you back them up.
All that was changed in the three files was the extention of pin numbers defined and processed (pins 55 to 69).

Arduino IDE 2.3.9 compiles but fails to upload to Devboard with this error: "Platform 'Teensy:avr' not found".
I'm not smart enough to know why :unsure:
Really did not spend much time looking for the reason why. Have not tried setting up and testing with W11 yet. That's next...
Click to expand...
Ok, the repo is public again.
Updated core_pins.h, digital.c, pwm.c and boards.txt.
Added (-DDEV45) define to boards.txt to prevent DB4 & DB5 extened defines from being included in MicroMod defines when using a MicroMod device.
Also fixed and tested issues in post #12. Everything seems to work well...
 
PaulStoffregen said:
I've already added 25mV above what NXP says is needed, applied between 460 to 528 MHz. I hope you can understand when it comes to the default settings we ship in the software to everyone, this sort of extraordinary claim needs to be backed up by substantial evidence.
Click to expand...
But it's not the default "for everyone" - that's exactly why I initially suggested using the fuses to determine which voltage formula to use. Regular Teensy isn't going to be affected because it uses the commercial variant.
PaulStoffregen said:
However, I might add a separate function in the core library which lets anyone increase the CPU voltage without changing the clock speed. Anyone could also publish this as a library, since it's just hardware registers that are writable. If some highly demanding applications really do need an increase, hopefully having a library or special function would let those projects meet their needs, and maybe we could encourage people who use it to give feedback.
Click to expand...
I don't think this is necessary. It's already possible to include a local copy of clockspeed.c in a project (with any changes required) which will override the one provided by cores. It would just be more convenient if the core code knew to use more voltage when it sees the MCU is an industrial variant.
PaulStoffregen said:
But to make the default for everyone higher than we have now (which is 25 mV above what NXP says is needed), reproducible test cases are needed to unquestionably demonstrate the need to increase everyone's power consumption.
Click to expand...
Do you have a board with an industrial variant MCU? Otherwise I don't see the merit in providing a test case.
The issue with trying to provide a 100% reproducible test case is that it's a brown-out issue - the behaviour is extremely non-deterministic and the faults can happen in entirely different ways each time. The only give-away that they are related is that when you start examining the assembly code of the faulting locations, it becomes apparent that the faults are "impossible" - the register values don't match what is assigned in the code, or the chosen execution paths don't make sense - because the CPU isn't operating in a predictable way. This is why I really don't want other people to experience it.
 
Last edited:
jmarsh said:
That code doesn't use the SDRAM memory, only flash.
Click to expand...
Correct - two separate posts.

Only known use of SDRAM is the @Dogbone06 boards with Industrial MCU.
But if somebody wanted FLASHMEM code - it was there and seen to work on LOCKED (and unlocked) STD MCU's

It was just an idea to prove on the fly FLASHMEM LOCKED decode worked when it was large enough to work outside any cache, and was just a couple % slower than FLASHMEM not LOCKED or perhaps even TCM RAM run
 
wwatson said:
SDRAM IF is the only thing that needed the higher voltage setting?
Click to expand...
That was the first that caught attention and nothing else was a problem - but SDRAM test was priority with focus.
Been a while now ... If there were other 'low voltage' issues they didn't present as significant before voltage was raised and SDRAM tests passed even in excess of the SDRAM chip's 166 MHz spec to 200 MHZ, and above on some boards.
 
Ok, same installation procedure for W11 as in post #1 using Windows folders instead of Linux folders. Also something else I noticed today is that if you have Arduino 1.8.19 installed and then install Arduino IDE Arduino 1.8.19 compile uses ".arduino15/packages/teensy/hardware/avr" install instead of the normal "arduino-1.8.19/hardware/teensy/avr/" install. The same thing happens with Windows installs.
Therefore you will need to update "core_pins.h", "digital.c" and "pwm.c" in "arduino-1.8.19/hardware/teensy/avr/0.62.3/cores/teensy4" as well. Otherwise the sketch will compile and upload but not run...
 
wwatson said:
All that was changed in the three files was the extention of pin numbers defined and processed (pins 55 to 69).

Arduino IDE 2.3.9 compiles but fails to upload to Devboard with this error: "Platform 'Teensy:avr' not found".
I'm not smart enough to know why :unsure:
Really did not spend much time looking for the reason why. Have not tried setting up and testing with W11 yet. That's next...
Click to expand...
I am trying to decide if I have it in me, to update my Branch variants_override PR #750 to be up to date. Looks like the last time
I did that was two years ago.

My guess is it is still unlikely that any of this stuff would be pulled in to the main branch, but miracles do happen :D

EDIT: And if I do it, I will probably try to squash several commits into one when possible as to reduce the number of merge issues when I do rebase...
 
Last edited:
I'm planning to merge a lot of stuff in 1.63, but variant.h support is not in the plans.

Probably not the answer you want to hear, but hopefully a clear and honest answer is better than silence and uncertainty.
 
PaulStoffregen said:
I'm planning to merge a lot of stuff in 1.63, but variant.h support is not in the plans.

Probably not the answer you want to hear, but hopefully a clear and honest answer is better than silence and uncertainty.
Click to expand...
Understood - which is one reason why my boards are sitting on the shelf and/or in boxes in cabinet...
 
Quick update: I know there is about %.01 chance of any of this stuff merging, but I know a few may want to play with it.
I could not simply rebase... Could not squash commits... So I created a new branch and cherry picked:

Not sure if it works, but I cherrypicked a lot of the stuff. I then went to the Arduino15
and teensy setup , renamed cores cores_rel
and made a link: mklink /D cores d:\github\cores
And choosing the Devboard5 does compile blink...

But I have not tried anything yet to see if it works...
 
You must log in or register to reply here.
Back
Top