Hi,
I am experimenting with radio networking using six FRDM-K64F boards equipped with nrf23l01 transceivers.
I am splitting a second into ten time slots, the idea being that a transmission in slot 1 gets repeated in time slot 2, time slot 2 into time slot 3 etc for relaying.
So I am using PIT to generate interrupts at 100 ms periods, which I have checked on a scope.
On three boards, rev C,F, and F this is working fine and I am seeing the data on air being repeated. However with the three rev F1 boards my transmit routine gets hung waiting for time slot 1 to come around. I am not getting the interrupt!
Does anybody know what changed between, say rev F and Rev F1 that would cause this behaviour?
Here is my init routine:
SIM->SCGC6 |= SIM_SCGC6_PIT_MASK; // Turn on clock to to the PIT PIT->MCR = 0x1; // Enable PIT timers
PIT->CHANNEL[0].LDVAL = 5999999; // Set reload value to 100mS
PIT->CHANNEL[0].TCTRL = 0x03; // Turn PIT timer 0 on, interrupts on
and in main:
NVIC_EnableIRQ(PIT0_IRQn); // Enable PI timer, ch 0 interrupt
and the ISR:
void PIT0_IRQHandler(void)
{
/* Clear interrupt flag */
PIT->CHANNEL[0].TFLG = PIT_TFLG_TIF_MASK;
NVIC_ClearPendingIRQ(PIT0_IRQn); // Clear pending PI timer, ch 0 interrupt
//scope_trigger();
time_slot +=1;
if (time_slot >10) time_slot=0;
__DSB(); // Add for ARM errata 838869, affects Cortex-M4
}
any help appreciated!
cheers
nigel
Aha! Thanks for that. Yes I have that mask on all three chips. I'm surprised that your AI engine that I have found very useful so far did not bring that up! Is there a suggested work-around? A delay or nops maybe? And yes, the PIT->MCR = 0x1; should be on a separate line, the
Hi @ve3id
Thank you for your post!
Please review if the errata e7914 applies for your MCU: Kinetis_K_1N83J.pdf
I've tested it in FRDM-K64F REV F1 and it works, I used SDK 2.11.0 and MCUXpresso IDE 25.06.
Also, I notice that in the code you share the "PIT->MCR = 0x1;" is included as a comment in the enablement of the SCGC6, I only want to confirm if that is a typo in the post
Hi @ve3id
The workaround mentioned with the errata is to put a read of the PIT_MCR register before writing it.
I use the PIT example of the SDK as base to test what you are doing in a FRDM board REV F1, I modified as following
carlos_o_0-1790096350978.pngcarlos_o_0-1790096350978.pngcarlos_o_0-1790096350978.png
It works without issues.