Teensy 3.5: EEPROM and Encoder/Interrupt Interactions?

[madgrizzle]

I'm working with a Teensy 3.5 and I have a program that I'm porting that does analogWrites to a motor thousand times a second, while reading the motor's encoder and saving it to EEPROM. I found that the motor stutters when the encoder is connected (i.e., interrupts are being processed) AND the encoder reads are being saved to EEPROM. If I eliminate either (disconnect the encoder or skip saving to EEPROM), the motor runs smoothly. Is there any type of potential interaction between EEPROM.h and encoder.h? Does the EEPROM use certain pins that I need to avoid?

 

[madgrizzle]

Is there any relevance to using pins 22 and 23 (which are associated with FTM0) for generating the PWM signals? The encoder is using pins 18/19 if that matters.

 

[defragster]

I don't see where EEPROM writes disable interrupts - and it definitely does not affect any hardware pins. It does take 'some' time to complete the write that may affect the bus processing. On the T_3.5 the write isn't as much of an issue as on the T_3.6 when running over 120 MHz due to the processor design/speed.

EEPROM writes are only functional some 10's of thousands of times - maybe less, maybe more - but excessive overwrites to the same area will cause wear and also overhead as there is a wear prevention scheme in the hardware where the one eeprom area exposed is mapped across multiple areas - it is possible that remapping is being triggered and it may cause internal delays.

This battery backed NVRAM should be present on T_3.5. I put a battery on a T_3.1 22 days ago and it has been mostly unplugged and still holding the values I placed when I posted this :: Info-adc Not sure how much is being written - but this shows room for 14 values of 16 bits … 28 usable bytes.

Applying 3V battery power to the VBat pin will assure this area survives power loss, and writing will be faster than EEPROM, and not have issues with write wear or overhead of minimizing it.

 

[madgrizzle]

Thanks for the response... I'm going to fix the excessively excessive EEPROM write issue (I calculated its about 4500 EEPROM writes occurring each time this part is run.. good thing I have a spare teensy). The code should actually never write to EEPROM while a motor is moving.. long story.. not my code.. so the problem will go away very soon. I'm trying to figure out why it is happening in case I'm misunderstanding something.

I initially thought it might be a delay issue, but I don't have a problem if the encoder is disconnected because I believe it's doing the EEPROM writes. If EEPROM writes were taking too long, then that would likely still cause PWM issues. Likewise, I doesn't seem to be a delay issue with the encoder/interrupts because if I delete the EEPROM writes from the code, it doesn't cause PWM issues. It's only when both happen and its quite noticeable when it does.

 

[Kirah]

Haven't looked closely at this particular MCU's behavior, but most modern micros don't have any actual EEPROM anymore, they use a zone of the program flash memory to emulate it. It's typically got some timing implications as the flash is erased in relatively large blocks, so sometimes you writing just a byte means a ton of stuff happening in the background like copying contents of the block to a temp location, erasing the block (long, and on some parts halting the CPU completely because program memory can't be read while a block is being erased) then the whole block with your single modified byte being rewritten.

 

[defragster]

Noted above indeed ::

excessive overwrites to the same area will cause wear and also overhead as there is a wear prevention scheme in the hardware where the one eeprom area exposed is mapped across multiple areas - it is possible that remapping is being triggered and it may cause internal delays.