PaulStoffregen
Well-known member
Is that a Rigol 1000Z series scope?
Those are at most 100 MHz bandwidth, and have 150 MHz probes, right?
Those are at most 100 MHz bandwidth, and have 150 MHz probes, right?
Is that a Rigol 1000Z series scope?
Those are at most 100 MHz bandwidth, and have 150 MHz probes, right?
Volts 1052 3.5
5 21,801 21,155 (counts)
7.5 32,104 32,009
10 42,833 43,262
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....
33222222222211111111110000000000
10987654321098765432109876543210
--------------------------------
SPIO_MCR: 00000000000000000000000000000000
SPIO_CTAR_SLAVE: 01111000000000000000000000000000
SPI0_SR: 01000010000000000000000000000000
SPI0_RSER: 00000000000000100000000000000000
Frame Size: 16
Data Length: 256
Packets: 1
Bytes Sent: 512
Time Elapsed: 155
uSecs/Byte: 0.30
Mbps: 3.30
SPI CLK 20000000 master clock 261818172 261818172
fifo 16 watermark 8
txcount 256 257 us 15937 kbs
If you are not using 8-bit frame size, then you may have to worry about byte order. Conveniently, the 1052 LPSPI has a control bit to re-order bytes, BYSW in TCR.However the data printed didn't come over in sequential order - have to figure that one out. Been testing speeds and waveform but wanted to see if data transfers were actually working correctly
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".
data[0]: 231
data[1]: 232
data[2]: 233
data[3]: 234
data[4]: 235
data[5]: 236
data[6]: 237
data[7]: 238
data[8]: 239
data[9]: 240
data[10]: 241
data[11]: 242
data[12]: 243
data[13]: 240
data[14]: 244
data[15]: 245
data[16]: 246
data[17]: 247
data[18]: 248
data[19]: 249
data[20]: 250
data[21]: 251
data[22]: 252
data[23]: 253
data[24]: 254
data[25]: 255
data[26]: 252
data[27]: 13
data[28]: 14
data[29]: 15
data[30]: 12
data[31]: 16
data[32]: 17
data[33]: 18
void T3SPI::rx16(volatile uint16_t *dataIN, int length){
dataIN[dataPointer] = SPI0_POPR;
dataPointer++;
if (dataPointer == length){
dataPointer=0;
packetCT++;
[COLOR="#FF0000"]delay(1);[/COLOR]
}
SPI0_SR |= SPI_SR_RFDF;
}
1052 settings:
SPI CLK 60000000 master clock 261818172 261818172
fifo 16 watermark 8
txcount 256 121 us 33851 kbs
...
I measured milliamps while running the app on my EVKB board, and the results are in post #1
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.
4 days ago and updating ...
Anyone have any ideas on the 32 kHz crystal measurement?
uint32_t rtc_secs()
{
uint32_t seconds = 0;
uint32_t tmp = 0;
/* Do consecutive reads until value is correct */
do
{
seconds = tmp;
tmp = (SNVS->LPSRTCMR << 17U) | (SNVS->LPSRTCLR >> 15U);
// tmp = (SNVS->HPRTCMR << 17U) | (SNVS->HPRTCLR >> 15U);
} while (tmp != seconds);
return seconds;
}
...
uint32_t secs, us = 0, us0 = 0, secs0 = 0;
secs = rtc_secs();
while (1) {
if (secs != rtc_secs()) {
us = micros();
secs = rtc_secs();
if (us0 == 0) {
us0 = us;
secs0 = secs;
} else {
float ppm = 1000000. * (((secs - secs0) * 1000000.) - (us - us0))
/ (us - us0);
PRINTF("%d secs %d ppm %u us\n", secs - secs0, (int)ppm, us);
}
}
}
#include "debug/printf.h"
void setup() {
// Connect GPS 1PPS signal to pin 30 (EMC_24)
IOMUXC_SW_MUX_CTL_PAD_GPIO_EMC_24 = 4; // GPT1 Capture1
IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_24 = 0x13000; //Pulldown & Hyst
CCM_CCGR1 |= CCM_CCGR1_GPT(CCM_CCGR_ON) |
CCM_CCGR1_GPT_SERIAL(CCM_CCGR_ON);
GPT1_CR = 0;
GPT1_PR = 0;
GPT1_SR = 0x3F; // clear all prior status
GPT1_IR = GPT_IR_IF1IE;
GPT1_CR = GPT_CR_EN | GPT_CR_CLKSRC(4) |
GPT_CR_FRR | GPT_CR_IM1(1) | GPT_CR_IM2(2);
attachInterruptVector(IRQ_GPT1, capture);
NVIC_ENABLE_IRQ(IRQ_GPT1);
}
#define LEN 124
void capture() {
static uint32_t prior=0;
static uint32_t list[LEN];
static uint32_t count=0;
static int index=0;
uint32_t now = GPT1_ICR1;
GPT1_SR = GPT_SR_IF1;
uint32_t n = now - prior;
prior = now;
if (index >= LEN) index = 0;
list[index++] = n;
count++;
if (count <= LEN) {
printf("cature %u\n", n);
} else {
uint32_t sum=0;
for (int i=0; i < LEN; i++) {
sum = sum + list[i];
}
printf("cature=%u, sum=%u\n", n, sum);
}
}
void loop() {
}
This probably can't work on NXP's eval boards, unless you cut the EMC24 trace going to the SDRAM chip...
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