Messages

16

NXP^TM M522XX, KINETIS and i.MX RT / Re: SD Task locking

« on: June 16, 2021, 12:06:50 PM »

Hi Mark,

Good and bad news

The good news is that the problem seems to have been fixed. The bad news is that if I remove the code that switches the mass storage task  to polling mode from the fnSendSDCommand() function, the SD card initialization doesn't work at all anymore. So what I've done as a quick test and hack was declare a global variable that doesn't allow the mass storage task to be switched to active state once I begin writing to file and this seems to have cured the problem. Saying that, I need a better permanent solution of synchronizing, I was thinking of keeping this global variable solution and just adding a mutex to synchronize access to it from the two FreeRTOS tasks. Can you see any potential issues with this approach?

PS: There are a couple of SD-related functions that allocate relatively large buffers (512 bytes) on the stack. Is that intentional?

Thanks!

17

NXP^TM M522XX, KINETIS and i.MX RT / Re: SD Task locking

« on: June 14, 2021, 12:09:32 PM »

Assuming that the basic issue is conflicts between the task running and the writes (pre-emptive) you could check to see whether one of these is being triggered (maybe by the pre-emptive writes) and remove the re-scheduling commands (possibly redundant anyway).

I made it such that I never attempt to write while the MASS_STORAGE task is active - indicating there're still operations to be finalized.

I'm debugging using four pins to signal various events across the application and can see that the writes start taking longer for a particular cluster and that the locks that actually bother me are coming from the MASS_STORAGE scheduling that sometimes occurs from this line

Code: [Select]

fnLoadPartialData(ptr_utDisk, ulClusterSector, (unsigned char *)&ulCluster, (unsigned short)((ptr_location->ulCluster & 0x7f) * sizeof(unsigned long)), sizeof(unsigned long)) in the

Code: [Select]

fnNextSectorCreate() function. To be honest, I'm not sure I can debug this further as it takes a rather long time to reproduce (around 30 minutes) and there's limited information that I can gather each time. My main concern is keeping the other uTasker tasks running and try to somehow recover the SD card operations afterwards.

Attached are two screenshots from my logic analyzer showing the events before a crash. "normal.png" shows what normal operation looks like, while "locking.png" shows the events just before everything locks.

D1 - low - MASS_STORAGE task active (when everything runs as expected, there's no activity here). Just before a crash I can see loads of postponed writes being done through the MASS_STORAGE_TASK
D2 - low - my datalogging task writing to file
D3 - toggling - each state is one full cycle of processing activity that needs to happen in the application
D4 - low - moving over a cluster boundary

My conclusions are that the SD cards starts to react much slower than usual (high activity on the MASS_STORAGE task), then, as it tries to move to the next cluster, it locks while trying to read/create the required filesystem data for the next cluster.

18

NXP^TM M522XX, KINETIS and i.MX RT / Re: SD Task locking

« on: June 07, 2021, 03:19:06 PM »

Thanks, Mark! Unfortunately it's still doing it even after removing the T_CHECK_CARD_REMOVAL define.  What I'm seeing is that the fnMassStorageTask() is activated by the fnSendSD_command() .

I've started going into the code behind the SD operations and I can get an idea of what is happening, but not why I'm afraid. In my datalogging FreeRTOS task I call utWriteFile(), as I mentioned earlier. As it writes data, I can see that after a short time, there are more and more calls to fnSendSD_command() required to perform the write. That also activates the MASS_STORAGE task which then gets blocked at the line below and locks the main processing task as well. I'm writing in 512 bytes chunks 50 times per second, so I don't expect there to be any issues with write speed.

Code: [Select]

while ((SDHC_PRSSTAT & (SDHC_PRSSTAT_DLA | SDHC_PRSSTAT_SDOFF)) == SDHC_PRSSTAT_DLA) { // ensure that the previous command has completed (in multiple block reads the clock may be gated off to pause and so this is accepted)
What I also noticed is that utWriteFile() returns success even if the underlying fnCommitFileInfo() call returned ERROR_CARD_TIMEOUT.

PS: The problem is much more likely to appear as the system is responding to relatively high frequency pin interrupts that have the highest level of priority in the system and thus can pre-empt any other operation, which makes me think the issue is somehow directly related to that. Furthermore, it comes only when the writes pass the sector size boundary of 4096 bytes (every 8 writes). Hope this information helps.

19

NXP^TM M522XX, KINETIS and i.MX RT / Re: SD Task locking

« on: June 03, 2021, 02:45:55 PM »

Hi Mark,

I only got the chance to look closer into this, both the datalogging FreeRTOS task and the uTasker FreeRTOS Task are running with the same priority. The only thing that's done through the datalogging FreeRTOS task is the actual file writing. Now, the way our application is structured, there's no guarantee that the user has an SD card inserted, nor that he wants to log data to it. Is there any document which details the operation of the fnMAssStorage() task? As I understand its operation now, I have a few questions:

1. I noticed that it rarely runs once data is constantly being written to the filesystem. I haven't dug too deep, but seems odd to me, as I don't see where the task is suspended in the code and I think it should run for every iteration of the main uTasker FreeRTOS task.
2. When you mention "disable the polling option", do you mean disabling the entire fnMassStorage() task? I was thinking to suspend it once I start logging to file and resuming it once that's done.

Regards,
Alex

Further observations: when the utWriteFile() locks, the fnMassStorage() task comes alive much more often.

20

NXP^TM M522XX, KINETIS and i.MX RT / SD Task locking

« on: May 27, 2021, 03:00:48 PM »

Hi,

Our firmware's architecture involves two FreeRTOS tasks, one running uTasker and the other periodically calling utWriteFile() at a frequency of around 50Hz. What I saw was that the fnMassStorage task would simply lock trying to talk to the SD card, essentially blocking all the other uTasker tasks from running. Unfortunately due to other issues I wasn't able to dig deeper into the problem, but was curious as to whether this has been seen before. We are currently running uTasker with Git commit SHA1: 3c417a7002c9d9840e025bb445208070a62327df

Thanks!

21

NXP^TM M522XX, KINETIS and i.MX RT / Re: Swapping MCUs mid-production

« on: April 28, 2021, 06:37:14 PM »

Thanks for the speedy reply as always, Mark. Unfortunately the factory wasn't able to secure that stock and we're now faced with the possibility of swapping to a totally different MCU. I'm wondering, how extensive would the porting operation be for the following types of changes:
1. Swap to another Kinetis with a slightly altered memory structure and package
2. Swap to another Kinetis with another Cortex core
3. Swap to a totally different MCU family, hopefully still with a Cortex core.

Thanks!

22

NXP^TM M522XX, KINETIS and i.MX RT / Swapping MCUs mid-production

« on: April 14, 2021, 04:14:28 PM »

Hi,

The MCU we were using, MK66FN2M0VLQ18 is unfortunately hit by the worldwide chip supply shortage and won't be available for another year. So currently trying to asses the feasibility of switching to a similar MCU, while keeping our new firmware compatible with the old MCU (customers can do firmware updates and we don't want to double the number of firmware lines we maintain). The processor I think would work well is the MK26FN2M0VLQ18, as we aren't using any of the extra features on the K66. What changes would be required in the firmware for this switch? As far as I can tell, the clock configuration stays the same and the linker file is identical given that it's also a 2MB and 256KB of RAM device. Anything we're missing?

Thanks!

23

USB / USB CDC initialization on Kinetis K66

« on: April 06, 2020, 11:02:14 AM »

Hi,

So we've been running uTasker and USB successfully on our product for quite a while now. Unfortunately, we've had a few USB-related failures where the customer would plug the cable in his laptop and the MCU would just die and take D6 out as well.  Now, as you can probably see, we have an odd setup, there the 5V derived from our main 12V supply is fed into the USB5V line coming from USB through a diode and then going into VREGIN pins and powering the USB transceiver.

The reason we had to do this was to have the USB transceiver powered in order to initialize it at power-up, but I think we've done it wrong. Is there any way in which we can remove D6 and essentially only have VREGIN powered when the USB is plugged in? Detecting the "USB plugged" event and only initializing USB then.

Thanks!
Alex

24

µTasker general / Re: CAN TX Timeout

« on: January 30, 2020, 11:13:55 AM »

Hi Mark,

Did you get a chance to look into this? If not, I'll just modify my code so that the first set of messages always go with TX_ACK set on and do that.

25

µTasker general / Re: CAN TX Timeout

« on: January 17, 2020, 06:13:57 AM »

Thanks, Mark! Looking forward to it as it's a bit of a blocker at the moment. I did a bit of my own digging and it seems like there's no code path to handle a flush request on a CAN interface.  As you know I'm on the old uTasker version (Jan 2019), so not sure if you've added anything in between.

Regards,
Alex

26

µTasker general / Re: CAN TX Timeout

« on: January 15, 2020, 02:27:05 PM »

Very happy to monitor with the application, but not sure how I can abort and flush the buffers. It is indeed a passive error, where the other device on the bus (and the termination resistor as a consequence) are not active initially after my device starts.

Thanks!

27

µTasker general / CAN TX Timeout

« on: January 14, 2020, 01:08:08 PM »

Hi,

Using uTasker (with excellent results) on an automotive project. On the CAN-side of things I'm seeing a peculiar behaviour in a specific corner case. The corner case is one where my device is the only device switched on the CAN bus with another, that should receive my messages, being turned on a few seconds later. What happens is that the TX buffers quickly get filled up, but, oddly, they don't ever timeout, contrary to what's described in the documentation. The documentation suggests that the buffers will be freed after a certain number of retries.

After looking through the code, I noticed that the CAN_TX_BUF_ACTIVE flag is only cleared in case there's no ACK coming, not if the message can't be sent. Page 10 of the uTasker CAN documentation suggests that the expected behaviour is for the buffer to be returned to an inactive state by the driver, informing the application that the message couldn't be delivered.

        if ((ulError & CAN_ACK_ERR) != 0) {                              // a transmission received no ack
            (...)
            while (i-- != 0) {
                if ((ptrCanQue->ucMode & CAN_TX_BUF_ACTIVE) != 0) {      // this buffer is presently transmitting a message
                    if (++(ptrCanQue->ucErrors) >= MAX_TX_CAN_TRIES) {   // we allow a few attempts before quitting (it also filters counting normal active buffers)
                        ptrMessageBuffer->ulCode_Len_TimeStamp = ((ptrMessageBuffer->ulCode_Len_TimeStamp & ~CAN_CODE_FIELD) | MB_TX_INACTIVE); // stop transmission
                        can_error_int_message[MSG_DESTINATION_TASK] = ptrCanQue->TaskToWake;
                        if ((ptrCanQue->ucMode & CAN_TX_BUF_REMOTE) != 0) {
                            can_error_int_message[MSG_INTERRUPT_EVENT] = CAN_TX_REMOTE_ERROR;
                            ptrCanQue->ucMode = (CAN_TX_BUF | CAN_RX_BUF_FULL | CAN_TX_BUF_REMOTE); // mark that it is an errored transmission buffer
                        }
                        else {
                            can_error_int_message[MSG_INTERRUPT_EVENT] = CAN_TX_ERROR;
                            ptrCanQue->ucMode = (CAN_TX_BUF | CAN_RX_BUF_FULL); // mark that it is an errored transmission buffer
                        }

28

utFAT / Re: SD write speed and processor load

« on: January 25, 2019, 03:47:44 PM »

Hi,

I managed to get 100 KB/s by using FAT32 instead of FAT as a filesystem on that particular card. You mentioned at #3 using block mode. Did you mean simply writing data in 512 byte chunks or were you referring to a setting of some sort?

Thanks again for your input. The current settings would yield a 4.8ms increase per loop iteration which, although not ideal, is very encouraging as it means the FreeRTOS solution could be used and not interfere with the actual operation. A 50Hz write frequency would only increase the loop time to around 2.2ms, which isn't a problem at all.

Alex

29

utFAT / Re: SD write speed and processor load

« on: January 24, 2019, 08:03:28 PM »

Mark,

Thanks for your speedy reply. I think my particular use case should allow me to do some neat optimizations that should broaden the number of options available. Essentially, the card will never have to be written to and read from randomly. It will write to a file for a number of minutes, then the writing will stop and the file will be read and then sent to the PC through USB. Also, my writes are always sequential and of the same size, depending on the user's configuration. When you say it only helps with linear blocks, do you mean I should always write more a multiple of block size data or the speed-up totally dependent of the SD card's filesystem organization?

I'm a bit reluctant to commit to a big switch such as using FreeRTOS so late in our project, so I was thinking I could obtain the same effect by dividing the data to be written in multiple chunks. I have quite a bit of leeway in terms of the variation of the main processing task (can easily go up to 3-4ms without affecting the functioning of the product). I'm quite surprised because I've seen benchmarks with the Kinetis that got way more than the measly ~20KBps I got with my first test. I'm thinking it could be the card, so I'll do some more testing over the next few hours and see where we end up.

Thanks,
Alex

30

utFAT / SD write speed and processor load

« on: January 24, 2019, 04:36:21 PM »

Hi,

We run a Kinetis K66 with a microSD card slot connected in 4-bit mode. I've done some basic benchmarks this morning with the standard write size we're going to be doing most of the time (1.4KB) and I noticed some that the main iteration time for the main task reduced significantly. It used to be able to run one processing iteration every 1.7ms. After I've added the 1.4KB writes to it, the duration for one iteration increased to 10-35ms. Is there any setting in utFAT that would improve things? The file system I've used when formatting was FAT32 and the default allocation unit size.

Thanks,
Alex