What is the maximum length of time interrupts can be disabled?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

What is the maximum length of time interrupts can be disabled?

Jump to solution
1,575 Views
mykepredko
Contributor IV

Hey Folks,

 

I'm doing some writing to the Flash and to ensure there aren't interrupt caused issues I'm disabling interrupts during the writes (using _int_disable(); followed at the end of the writes by _int_enable():smileywink:

 

Is there any limit to how long interrupts can be disabled?  Are there any components that I should be aware of?  Along with the standard MCF52223 BSP, I'm also using USB. 

 

I'm asking because the number of writes is dynamic and, if required I can re-enable interrupts to have them serviced and then go back to the writes.

 

Thanx,

 

myke

0 Kudos
1 Solution
574 Views
JuroV
NXP Employee
NXP Employee

If you use CDC class, then after successfull enumeration, you don't need to have interrupt enabled for short time. The computer host will ask for data and if no data is present, your device will respond with NAK packet automatically without interrupting device, if there is no data in endpoint's buffer descriptor.

 

For enumeration, this applies (from USB 2.0 Specification):

 

9.2.6.4 Standard Device Requests
For standard device requests that require no Data stage, a device must be able to complete the request and
be able to successfully complete the Status stage of the request within 50 ms of receipt of the request. This
limitation applies to requests to the device, interface, or endpoint.
For standard device requests that require data stage transfer to the host, the device must be able to return the
first data packet to the host within 500 ms of receipt of the request. For subsequent data packets, if any, the
device must be able to return them within 500 ms of successful completion of the transmission of the
previous packet. The device must then be able to successfully complete the status stage within 50 ms after
returning the last data packet.
For standard device requests that require a data stage transfer to the device, the 5-second limit applies. This
means that the device must be capable of accepting all data packets from the host and successfully
completing the Status stage if the host provides the data at the maximum rate at which the device can accept
it. Delays between packets introduced by the host add to the time allowed for the device to complete the
request.

View solution in original post

0 Kudos
7 Replies
574 Views
JuroV
NXP Employee
NXP Employee

The answer to this question is quite complex.

1. MQX ticks, depending on BSP, counting time: if you miss a tick interrupt, you miss clock counter.

2. USB host will be just slower, but for SETUP transactions it can be problem, as SETUP transactions can take up to 2 interrupts: SETUP packet and then IN / OUT packet. If IN / OUT packet is sent / received too late from SETUP, a device can consider that as an error, then followed delayed IN / OUT packet can be also considered as an error. But good device should recover from these errors. But if the device responds STALL for standard request, MQX host may not recover properly from that situation (will reject device).

3. USB device can be a problem for SETUP transactions from the same reasons in [2]. An application must respond fast for SETUP transactions as the computer USB host can consider device not ready...

 

I did not understand this: "I'm asking because the number of writes is dynamic and, if required I can re-enable interrupts to have them serviced and then go back to the writes."

 

0 Kudos
574 Views
JuroV
NXP Employee
NXP Employee

Sorry, I was considering EHCI- based USB peripheral. For mcf522x, the USB-OTG IP performs SETUP + IN in one task that cannot be interrupted => the host will run... The situation for USB device remains the same as described in previous post.

0 Kudos
574 Views
mykepredko
Contributor IV

Hi Juro,

 

Thank you for getting back to me. 

 

The question regarding suspending interrupts is in regard to the situation where the ColdFire is connected to a PC as a CDC device and it is downloading new data from the PC while it is programming this data into the Flash.  I don't think missing MQX ticks will be an issue for the application (no critical timing or operations taking place when the download/programming is happening). 

 

The line that you weren't sure about was me asking because the amount of data will be different at different times and the length of time the interrupts are disabled could range from relatively short (say a few 10s of ms) to several seconds. 

 

To avoid any potential issues, is there a time interval that I should re-enable interrupts during the Flash writes to ensure that any USB and other (timer being the big one) interrupt requests are not lost or overwritten?

 

Thanx,

 

myke

0 Kudos
575 Views
JuroV
NXP Employee
NXP Employee

If you use CDC class, then after successfull enumeration, you don't need to have interrupt enabled for short time. The computer host will ask for data and if no data is present, your device will respond with NAK packet automatically without interrupting device, if there is no data in endpoint's buffer descriptor.

 

For enumeration, this applies (from USB 2.0 Specification):

 

9.2.6.4 Standard Device Requests
For standard device requests that require no Data stage, a device must be able to complete the request and
be able to successfully complete the Status stage of the request within 50 ms of receipt of the request. This
limitation applies to requests to the device, interface, or endpoint.
For standard device requests that require data stage transfer to the host, the device must be able to return the
first data packet to the host within 500 ms of receipt of the request. For subsequent data packets, if any, the
device must be able to return them within 500 ms of successful completion of the transmission of the
previous packet. The device must then be able to successfully complete the status stage within 50 ms after
returning the last data packet.
For standard device requests that require a data stage transfer to the device, the 5-second limit applies. This
means that the device must be capable of accepting all data packets from the host and successfully
completing the Status stage if the host provides the data at the maximum rate at which the device can accept
it. Delays between packets introduced by the host add to the time allowed for the device to complete the
request.

0 Kudos
574 Views
mykepredko
Contributor IV

Thanx Jufo. 

 

I think that's the reference information that I'm looking for.  

 

Now, where can I find the time required for an erase?  I believe a word program is determined by the CFMCLKD register and I'm setting it to 200kHz frequency (5us period), so if I enable interrupts after every 64 cycles, this will be a delay of 320ms which is within the limit of the standard device requests although it does not meet the 50ms requirement. 

 

So, I should probably enable/disable interrupts after every 4 word program operations to reduce this time to around 20ms to ensure the reply is within the stated limits.  Correct? 

 

Where can I find the timing for the Flash page erase commands?  I've looked through the RM & DS for the part.  I would guess that it takes around 20ms to erase a page (based on my experience with other devices) - is this a valid guess?

 

Thanx,

 

myke

0 Kudos
574 Views
JuroV
NXP Employee
NXP Employee

I will reply with another proposal (idea):

 

do you exactly need to have enumeration run during erasing? Because, usually, enumeration is done at startup, after that there is standard CDC communication. If you won't do any CDC line state settings (like baudrate, number of stop bits changes) during communication, then you will not receive any SETUP packet and you don't need to think about erase interrupts.

0 Kudos
574 Views
mykepredko
Contributor IV

Hi Juro,

 

You're exactly right.  I do not need to consider programming/erasing during enumeration. 

 

Sorry, I should have thought that through.

 

Thanx,

 

myke

0 Kudos