If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Pretty sure the key to high sustained LPSPI throughput for a larger block of data is configuring a big frame size in TCR. It's on my list to do soon. Right now dealing with the finer points of USB VBUS detection and dynamically reprogramming the LDO power supply settings....

Since I couldn't get the basic spi_interrupt example running on the 1052 board decided to give the basic quadrature encoder/decoder example a try and compare it to what I got from a T3.5 using the encoder library. For this initial test I use a 12v uxcell. Both gave me pretty much the same values at 12v, approximately 4400. Going to be a little more scientific about this in the next post as I just want to see if the example worked. There are a couple of nice features they add.

For some strange reason I still can not get the lspi_interrupt example to work - just hangs. So, finally dug out my scope from storage and think I figured out how to use it again. I played around with the example file and looked at clock and mosi. The clock freq was at 262Mhz and ran the test with a SPI rate of 80Mhz. I am posting the photo but not sure its right. Can someone give me a sanity check. I did make the modifications to the pad configurations, and used delays of 100ns:

Bottom trace is the clock and top trace is mosi.

Thanks
Mike

EDIT: just as a fyi the scope is a hantex dso5102P (100Mhz). There is a hack to get it up to 200Mhz but haven't done it yet. If you all think its worth it I will give it a try.

Pretty sure the key to high sustained LPSPI throughput for a larger block of data is configuring a big frame size in TCR. It's on my list to do soon. Right now dealing with the finer points of USB VBUS detection and dynamically reprogramming the LDO power supply settings....

Out of curiosity I ported the T3.0 Slave Library to run on the T3.2 and attached it the 1052 board using example master interrupt from the SDk. To get it work I did have reduce the framesize to 16, SPI clock to 20Mhz and the transfer size to 256 (limitation of the slave library). Data did come across from the 1052 to the T3.2 with the following results:

I'm always amazed the sheer volume of extra stuff to read just to figure out what anything really does. I suppose programmers who write code in that style feel it's good practice. Or maybe NXP has corporate requirements documents & standards which require all code written & formatted a certain way? I'm sure it's all done with the best of intentions, but the end result is an excessive amount of verbiage to sift though, just to figure out what anything actually does.

I really don't like that highly verbose style. My preference could be summed up as "less is more".

Just a followup to my SPI testing using I teensy as a slave. I attached a T3.5 and had set the 1052 to transmit at 60Mhz - data came across correctly. Was a bit surprised at this - but to make it work I had to overclock the T3.5 to 168Mhz, at 120Mhz would get data errors.

...
I measured milliamps while running the app on my EVKB board, and the results are in post #1

Funny the numbers are about as to be expected according to my calculator … except it doesn't mention the 90 ma base current The eval board has quite a few added components right? Can you add the board current when the MCU is sleeping?

To test power consumption at different frequencies, I ran the SDK power_mode_switch app, described here, with meter and hacked USB cable. At 600 MHz the app/board consumed 158.9 ma, @528mhz 150.3 ma, @132mhz 116.9 ma, and @24mhz 93.9 ma. The specs say the MCU should consume 0.11ma/MHz.

Yup, I finally started bringing in the many C-only "experiments" into Arduino.

At this moment I have 11 high priority items on my list which need to be completed before we start shipping beta boards. None are in the core library, so don't expect to see too much more activity on github for the next few days.

Let's talk about 2 of those 11 items: testing the crystal accuracy (on the 24 MHz crystal and the 32.768 kHz crystal). We don't get software trim-able capacitors like on Teensy 3.x. As a result, we built the first batch of betas with a variety of capacitor values. Right now, each board is in its own anti-static bag with the capacitor values used. We also used 5 different inductors for the DC-DC step down power supply. Before we send these out, I want to make some uniform measurements on all of them. (power efficiency measurement makes 3 of 11....)

For the 24 MHz, I can use analogWriteFrequency and use a frequency counter. I recently bought a low-end 10 MHz GPS disciplined oscillator (still sitting unused) for my frequency counter's reference input. FWIW, the counter is a BK Precision model 1823A.

Still searching for ideas to verify the 32 kHz oscillator. Sadly, I didn't being out the AD_B0_00 pin (BGA location M14) to a test pad. D'oh! Hindsight....

On the NXP eval board i measured 24mhz crystal drift with both ntp and GPS pps. For the 32khz, i configured up the SRTC and each time the second value changed, I compared to micros(), so I measured 32khz drift relative to 24mhz drift. On the SDK, my "micros()" is the free-running GPT timer. I started with one of the SDK examples that tested the SRTC ... holler, if you want more details/code. My drift values are in post #1

Surprisingly ? the RTC drift was -46 ppm. BOM says 32khz should be 20 ppm. So the eval board may have sub-optimal capacitors for 32khz crystal.

This probably can't work on NXP's eval boards, unless you cut the EMC24 trace going to the SDRAM chip...

Sigh, and the GPT2 capture pins (EMC_40 41) go to the ENET on the eval board. With less precision, one could free-run the GPTx on the 32khz clock source, and read the GPTx counter on each GPS PPS interrupt.

I'm seeing a strange difference between between the 2 oscillators. Or maybe not so strange... but still getting used to the little unexpected behaviors of this chip.

We built all the betas with a 24 MHz crystal rated at 12 pF. Except at least 2 got made with the wrong crystal, and maybe 2 more (haven't looked at those under the microscope yet), which makes for interpreting the data more interesting! The 32.768 kHz crystals are rated at 12.5 pF.

So far I haven't found any NXP specs on the pin capacitance. Most chips I've used have been in the 5 to 8 pF range per pin (ref to ground). Intuitively I was expecting the two oscillators to be similar. But that's definitely not what I'm seeing in the testing. We built the betas with capacitors ranging between 12 to 20 pF, expecting somewhere in the middle of that range would be needed. 12 pF turns out to be very close to ideal for the 24 MHz oscillator, and 20 pF looks pretty close on the 32.768 kHz. It's almost like NXP put little 7 pF capacitors inside the chip on the 24 MHz oscillator. Or maybe one set of pins really does have ~5 pF capacitance and the others about 13 pF?

I've measured both oscillators on 22 different boards. All those tests were done shortly after powering the board up, about 30 seconds for the 24 MHz and the first 4 minutes of running with the 32 kHz test. Now I'm starting a couple longer tests. On 2 different boards, I'm definitely seeing the 32 kHz oscillator starts running a bit fast and gradually slows over several minutes. With the board on my desk right now, the slowing from start to 15 minutes look to be ~3 ppm change.

since i.MX and Vybrid parts use many same IP modules and particular XTALOSC,
crystals mentioned on that thread also can be used with RT1050. Seems most full
characteristics are given in Table 9. Recommended External Crystal Specifications
i.MX25 Datasheet https://www.nxp.com/docs/en/data-sheet/IMX25CEC.pdf

Don't know if this helps or not, its about the only thing that I could find.