Pins to bring out on a hypothetical larger Teensy4

Status
Not open for further replies.
It's too late to consider a different flash chip for Teensy 4.1. Winbond W25Q64JV is already designed in and parts have been ordered.

But maybe a different flash chip would make sense for the next Teensy (after 4.1) with the 1170 chip?
Too bad we got to you too late...
Try it out for new designs, you will not be disappointed by the performance.
There are several different starter kits available as well if you want to try this out on the lab bench.

[...] Does Adesto have any octal SPI RAM chips?
I wish we did, they would complement our EcoXiP product line very well.

There are actually very few companies in the world who make DRAMs, and even fewer of these bother to make small devices. (PSRAMs are all built on DRAM technology, you do not want to pay for an SRAM that big.)

The one company I am aware of that build devices that can be an alternative to the Cypress/ISSI Hyperflash is AP Memory.
http://www.apmemory.com/html/product_psram.php

If you do a google search for "octal PSRAM", "xSPI RAM" or "XCCELA RAM" you will find some other suppliers, but in most cases I believe these are the same devices as the ones listed above. Just shop around to find who will give you the lowest price for the quantity you need.
 
I haven't looked now at the details of coremark, but I think that I remember it's small and fits into the cache completely(?) So it wouldn't be a good test for memory speed, and you might get even better numbers with a different benchmark.

But yes, the cache is very good.

Correct, CoreMark by itself is specifically designed to test the core, and therefore will fit in the cache.
There are no good benchmarks out yet that will test the performance of XiP systems. Most customers test their own code to see what performance improvement they get.
CoreMark is still used because customers are used to this one, and want to see numbers allowing them to compare new MCUs to the one they are using today.
The way NXP (and we) are getting around the CoreMark limitation is by invalidating the cache at certain intervals to force reads from flash (or other code storage memory).

The other weakness of this benchmark is that you are really only measuring average performance. If you care about peak performance (interrupts, task switching, loading graphics images, reading AI inference tables etc.), CoreMark will not show that well. Then you are better off comparing the raw bandwidth of the memory interface.

There are a few document available if you want to go deeper into details here.
https://www.nxp.com/docs/en/white-paper/NXPADESTOWP.pdf
https://www.embedded-computing.com/iot/is-your-quad-device-choking-your-system-performance
https://www.embedded-computing.com/...d-performance-requirements-of-edge-iot-and-ai
 
On distinguishing boards having the same IMXRT 1062 chip, Teensyduino 1.50 will start using Arduino's convention of -DARDUINO_{build.board}, where "build.board" is a unique name for each board defined in boards.txt.

So in C++ or C code, you would do this:

Code:
#if defined(__IMXRT1062__)
  //
  // code for either Teensy 4.0 or 4.1
  //
#endif

#if defined(__IMXRT1062__) && defined(ARDUINO_TEENSY40)
  //
  // code for Teensy 4.0 only
  //
#elif defined(__IMXRT1062__) && defined(ARDUINO_TEENSY41)
  //
  // code for Teensy 4.1 only
  //
#endif

Or you can just use these without the __IMXRT1062__ check, like this

Code:
#if defined(ARDUINO_TEENSY40)
  //
  // code for Teensy 4.0 only
  //
#elif defined(ARDUINO_TEENSY41)
  //
  // code for Teensy 4.1 only
  //
#endif

On the pin assignments, preserving the Teensy 3.6 form factor is going to take precedence over preserving the SDIO pin numbers. So if you use digitalWrite(34, HIGH), on Teensy 4.1 that will control the pin in the same physical location as it does on Teensy 3.5 and 3.6.

t36card.png

On Teensy 4.0, using digitalWrite(34, HIGH) controls the SDIO DAT1 pin. To control that SDIO DAT1 pin on Teensy 4.1, you would use digitalWrite(42, HIGH). Unfortunately we can't preserve the 6 digital pin numbers for these SDIO pins and also have the breadboard-friendly digital pins consistent between Teensy 3.5, 3.6 and 4.1. The outside through-hole pads take priority.
 
@BardPedersen,

is it possible for me to request a few samples? I'd be interested in the larger SOIC packes (they are more "maker" friendly")

I've writen some code to interface some other chips (mainly memory) in the past - for the teensy 3.x series - but nothing for Teensy 4 so far and would be interested to do so, and perhaps create a addon-board for the comming T4.1
 
Those #ifdef's look usable and clear. Will that just cover the 4.x Teensys - or include the 3.x's as well? And indeed keeping same pin numbers makes sense

From p#1 : 'Another feature I'm considering is using the bottom side for locations to add 1 or 2 QSPI memory chips'
regarding such QSPI locations that might be on the larger T_4.1 :: does the MCU have means to memory map those for any(some) chip type?
 
@BardPedersen,

is it possible for me to request a few samples? I'd be interested in the larger SOIC packes (they are more "maker" friendly")

I've writen some code to interface some other chips (mainly memory) in the past - for the teensy 3.x series - but nothing for Teensy 4 so far and would be interested to do so, and perhaps create a addon-board for the comming T4.1

There is a sample request link on the web page.
https://www.adestotech.com/products/octal/

There are no SOIC packages for these devices, though. Only BGA and WLCSP. That is why I would love to see them on a Teensy.
There are other development boards out there that use an i.MX RT device and an EcoXiP memory, including Adesto's version of the NXP starter kit, but these cost more than a Teensy.

I hope at least that the next Teensy will have all the FlexSPI pins routed out, so it will be possible to build an add-on board with EcoXiP. From what I can tell, the current Teensy 4.0 does not have the upper 4 bits of the octal bus available.

That solution may or may not be able to push the Flash interface speed all the way up to 266/300 MBytes per second. Octal DDR signals tend to be a bit picky on matching trace lengths so that all bits and the data strobe change exactly at the same time.

However, full FlexSPI clock speed is not required to get most of the performance out of the device. Our testing shows that the average performance increase of an RT1050 running at 600MHz is less than 5% when pushing the FlexSPI frequency from 100 to 150 MHz. At that speed, the bottleneck is somewhere in the MCU, running the flash faster does not make much difference.
 
Ok, I've ordered some samples of your soic memory. I tried to add a CBRAM, but it was not possible on the page. No problem. Thank you!
I am very curious if you deliver to "Makers" without company :)
In the past I had luck with TI and other companies.

The T4.1 will at least support additional quad-SPI, so I'll try this.
 
so it will be possible to build an add-on board with EcoXiP.

Teensy 4.1, like Teensy 4.0, will only use 3.3V I/O. I only looked quickly at your site, but got the impression all these parts need 1.8V signals. Are there any 3.3V versions?

Edit: tried to download the datasheet, but your site wants me to register. Really don't like that!

More bad news, at least on Teensy 4.1, the plan is only 4 bit data path to the extra memory locations. But at least it's a different 4 bit path than used for the main QSPI flash chip.


regarding such QSPI locations that might be on the larger T_4.1 :: does the MCU have means to memory map those for any(some) chip type?

Yes, FlexSPI maps these into the memory space.
 
Last edited:
Teensy 4.1, like Teensy 4.0, will only use 3.3V I/O. I only looked quickly at your site, but got the impression all these parts need 1.8V signals. Are there any 3.3V versions?
High speed DDR and 3.3V do not go well together. The few octal DDR devices that support 3.3V are limited to 100MHz. For XiP operation, you get the additional power consumption (power~V2) to deal with, so 1.8V has become the preferred option here.

Edit: tried to download the datasheet, but your site wants me to register. Really don't like that!
Me neither. I am trying to get that changed, but no luck so far. (I have a dedicated email to register to web sites I do not want to hear back from...)

More bad news, at least on Teensy 4.1, the plan is only 4 bit data path to the extra memory locations. But at least it's a different 4 bit path than used for the main QSPI flash chip.
That may actually be OK. The way NXP use the FlexSPI interface to an octal device, they use FlexSPI_D0_A - FlexSPI_D3_A for IO0-3 and FlexSPI_D0_B - FlexSPI_D3_B for IO4-7. That way you can have one octal or two quad devices in parallel using the same pins. Then you need CS', Reset', clock and data strobe. And an option for a 1.8V supply. As long as you do not connect NVCC_SD1 hard to your 3V supply, but connect it through a 0V resistor or a trace that can be cut and reassigned, it will be easy to connect a 1.8V supply.

If you put the two QSPI devices side by side, and the extra signals on two pads between them on the same pitch, it will be easy to just remove the main QSPI flash chip and drop down a 50-mil header (or 0.8mm if you are using the 4x4 package) to an EcoXiP adapter. The 1.8V regulator may also be on the adapter if you do not have room for the footprint on the main board. (You then need a 3.3V and a 1.8V pad for the adapter.) Or you can use a dual output regulator, they exist in the same package as the one you are using now.

We did something similar for an earlier NXP K82 board that was originally populated with two SOIC devices. Here the adapter was soldered directly to the board.
https://www.inteli-cs.com/wp-content/uploads/2017/10/Adesto-ECOXIP.jpg

You find the details for NXP's setup on page 11 in the schematics for NXP's MIMXRT1060EVK. The EcoXiP pinout is identical to the 1V8 HyperFlash described there, except that we do not need the CK', INT' and RSTO' signals.
If you do not already have the schematics, you can download the MIMXRT1060_EVK Design files from their web site. You just have to (ahem...) register :cool:
 
The way NXP use the FlexSPI interface to an octal device, they use FlexSPI_D0_A - FlexSPI_D3_A for IO0-3 and FlexSPI_D0_B - FlexSPI_D3_B for IO4-7. That way you can have one octal or two quad devices in parallel using the same pins. Then you need CS', Reset', clock and data strobe. And an option for a 1.8V supply. As long as you do not connect NVCC_SD1 hard to your 3V supply, but connect it through a 0V resistor or a trace that can be cut and reassigned, it will be easy to connect a 1.8V supply.

None of this will happen on Teensy 4.1. It's already far too late to consider these major changes.

There also just isn't PCB real estate for most of this. The extra space we're getting is allocated to a USB host connector and power switch like we have on Teensy 3.6, and the micro SD socket, and the ethernet PHY. The design has no 1.8V regulator at all.

Teensy 4.1 will bring out 4 signals from FlexSPI2 to a pair of SOIC pads, and 4 signals from FlexSPI1 go to the flash chip (those signals really aren't accessible), but neither of the two FlexSPI controllers will have all 8 of its signals routed. All the BGA escape routing has to happen on only 2 sides of the chip. The 42 I/O signals, 6 flash, 6 SD card, 7 QSPI for 2 chips and 12 ethernet PHY, 4 USB, and several misc signals have completely used up all the escape routing space. The PCB is already 6 layers with 5/5 mil spacing and 8 mil drill, which pushes right up to the limits before driving the PCB cost up much higher.

Even if we could get more signals out and have PCB real estate for pads or a connector, adding an octal interface flash hardly seems to make much practical sense. Faster flash is really only valuable if it's the main program storage memory, supported by the bootloader and default linker script. Sure, in theory someone could edit the build to compile software for the different memory range, and then go through a lot of trouble to get their data written into that memory. But in practice, pretty much nobody will go to that sort of effort. Teensy is all about informal making and rapid prototyping. An external flash chip that's hard to actually use would add very little practical value. It really only makes sense as the primary memory.

Octal flash might make more sense for the 1170 chip later this year. Even with only 4 bit interface, having read-while-write capability would be nice. We currently emulate EEPROM by stalling everything while the flash chip is busy writing.
 
On distinguishing boards having the same IMXRT 1062 chip, Teensyduino 1.50 will start using Arduino's convention of -DARDUINO_{build.board}, where "build.board" is a unique name for each board defined in boards.txt.

Is there a beta boards.txt including the changes somewhere?
 
Last edited:
Adesto:

... :-(
but at least their At45DB641E 64MBit flash uses a completely different pinout than other soic memories. So, not usable with the audioshield.


2020-02-06 22_39_17-Start.png
Audioshield and most other chips:
2020-02-06 22_40_14-Start.png

@others: Hopefully, this saves you the time trying it.
Spent my free time with this - ok my fault, should have read the Datasheet before.
Why don't they use the std-pinout?
 
Adesto:

... :-(
...Why don't they use the std-pinout?

The AT45 series devices are the "original" DataFlash devices defined by Atmel. (Adesto acquired Atmel's flash division in 2012.)

For both technical reasons (having Vcc and GND pins close together provides better decoupling at high speed than having them in the corners) and, presumably, for marketing reasons (preventing the new, lower cost flash devices from replacing more expensive serial EEPROM devices sold by a different division in the same company), the DataFlash devices were given a different pinout than the serial EEPROM devices.

When other flash vendors (who did not have a serial EEPROM product line) entered the serial flash market, they went specifically after the serial EEPROM market and made devices that are pin compatible to serial EEPROM devices. This became what is now considered "standard" serial flash. (Some also made DataFlash-compatible devices.)

Adesto continues to offer both pinouts, the AT25 series devices are lower cost standard flash devices with a minimum feature set, and the AT45-series devices are the the more feature-rich DataFlash devices.
 
@Paul,
is T4.1 on track, or significantly delayed?
I see some uploads on cores, so I assume you are doing some testing.
Do you have any feelings on how robust (mechanically) the T4.1 is? You remember some early issues with bending of T3.6?
 
At this point we're waiting on components.

While distributors are still promising the same lead times, whether the coronavirus quarantines in China will affect the global supply of electronic components over the next several months is unclear.

Obviously I want to release the new product as soon as possible. It's only a matter of components arriving and normal production times (done in the USA - so that part isn't affected by China).

Every indication is the Teensy 3.6 boards we're shipping today are quite solid. Since we released Teensy 3.5 & 3.6 in September 2016, we've switched PCB vendors and materials (the most recent PCBs have a pattern of 6 dots near the USB connector which we use to track the PCB process). Our contract manufacturer has "dialed in" their reflow process for these boards and Teensy 4.0 to a much greater precision than we had at initial release. So the products we're shipping today, while the same design, are very likely higher quality builds than when we started with BGA chips and 6-layer PCBs in 2016.

However, *all* BGA chips are sensitive to uneven heating. The failures I've investigated in the last year (we had several boards X-ray'd) all appear to be caused by accidental heating of the BGA while soldering the pins. I really can't speak to any issues from over 3 years ago where I did not personally get the failed or damaged boards back for testing. I'm not trying to deny any such problems may have happened... I'm only saying that the cases PJRC did investigate with X-ray work turned out to be uneven heating while soldering pins.

On the upcoming board, the design has been finalized & no more input or feedback is possible, so perhaps it's time to close this thread....
 
Last edited:
Status
Not open for further replies.
Back
Top