Recent Posts

Pages: [1] 2 3 ... 10
µTasker general / Re: PCA9698 I2C Setting
« Last post by ABBASID on June 22, 2021, 07:09:40 PM »
Will you be able to review my Keil code attached here which is simple code of writing "0" and "1" to pin 0, bank 0 (configured as output)?

When I debug my code, it gets stuck at line 221 of code inside function "I2C_WriteAccelReg". If I use function "I2C_MasterTransferBlocking" ( inside function "I2C_WriteAccelReg"), the code get stuck at line 952 of driver "fsl_i2c.c"
µTasker general / Re: PCA9698 I2C Setting
« Last post by mark on June 21, 2021, 06:36:45 PM »

Assuming that the PCA9698 is connected with AD0, AD1 and AD2 at GND its write address is 0x40 and its read address is 0x41.

To configure the first output (only) the transmission sequence is
0x40 0x18 0xfe
which will change it from its default input to output and it will drive '0'

To change it to '1' the transmission sequence is
0x40 0x08 0x01

To change it back to '0' the transmission sequence is
0x40 0x08 0x00

uTasker I2C interface code to do it (on I2C0 at 100kb/s) is:

define I2C_WRITE_ADDRESS   0x40
define I2C_READ_ADDRESS    0x41


    static const unsigned char ucConfigureOutput[] = {I2C_WRITE_ADDRESS, 0x18, 0xfe};
    static const unsigned char ucSetOutputHigh[] = {I2C_WRITE_ADDRESS, 0x08, 0x01};
    static const unsigned char ucSetOutputLow[] = {I2C_WRITE_ADDRESS, 0x08, 0x00};

    I2CTABLE tI2CParameters;

    tI2CParameters.Channel = 0;
    tI2CParameters.usSpeed = 100;                                        // 100k
    tI2CParameters.Rx_tx_sizes.TxQueueSize = 64;                         // transmit queue size
    tI2CParameters.Rx_tx_sizes.RxQueueSize = 64;                         // receive queue size
    tI2CParameters.Task_to_wake = 0;                                     // no wake on transmission termination
    I2CPortID = fnOpen(TYPE_I2C, FOR_I_O, &tI2CParameters);
    fnWrite(I2CPortID, (unsigned char *)ucConfigureOutput, sizeof(ucConfigureOutput));
    fnWrite(I2CPortID, (unsigned char *)ucSetOutputHigh, sizeof(ucSetOutputHigh));
    fnWrite(I2CPortID, (unsigned char *)ucSetOutputLow, sizeof(ucSetOutputLow));


µTasker general / PCA9698 I2C Setting
« Last post by ABBASID on June 21, 2021, 06:05:19 PM »
I am new to I2C protocol and trying to turn LED on/off connected to bank 0, pin 0 in MCUXpresso software by NXP. Would there be any code whihc I can use as reference  for I2C or atleast guide me how to configure PCA9698 for turning LED on/off ? What would be the sequence of device (slave) address, output configuration register and command register for output?
NXPTM M522XX, KINETIS and i.MX RT / Re: SD Task locking
« Last post by mark on June 17, 2021, 10:54:05 PM »

I am pleased to hear that you have found a workaround. Indeed, the mass storage task need to be able to perform polling during the mounting phase since this takes some time with the card reporting that is is busy at different stages.
As with any system that is shared by users that can pre-empt each other some form of protection is usually required and taking the mass-storage task's polling during normal operation out of the equation looks to have proven that one. Generally I think that some form of general mutex on any use of the file system would be the right way to do it.

There are some write operations that require a sector of the card to be first read, modified, and then written back. When these are performed in a single function a 512 byte buffer on the stack is used so what you have seen is normal. Any calling tasks require adequate stack size for this.


Would anybody be so kind to send me the sample code for nxp K60DX256VLL10 to communicate with PCA9698 over I2C protocol to turn led on/off for bank 0?
Thank you for your help. It was really helpful.

In the .scf file, following modifications were made;

#define m_interrupts_ram_start 0x1FFF8000
#define m_interrupts_ram_size __ram_vector_table_size__

#define m_data_start (m_interrupts_ram_start + m_interrupts_ram_size)
#define m_data_size (0x00008000 - m_interrupts_ram_size)

#define m_data_2_start 0x20000000
#define m_data_2_size 0x00008000

After this, code ran successfuly.
NXPTM M522XX, KINETIS and i.MX RT / Re: SD Task locking
« Last post by AlexS 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?

NXPTM M522XX, KINETIS and i.MX RT / Re: SD Task locking
« Last post by mark on June 15, 2021, 03:39:14 PM »
Hi Alex

I have used SD card to log data and have seen that the sometimes become very slow for a short amount of time. I believe that this is when the card is performing house keeping functions (clearing up deleted sectors and such) and these periods of remaining busy can last up to around half a second.

Since you see the mass storage task become active at the point in time the problem starts I assume that such a period of internal SD card activity has kicked in and the access timeout kicks the mass storage tasks into a polling mode after which (I still expect due to conflicts caused by pre-emption) a mass storage task subroutine hangs rather than timing out.

I would remove the mass storage task polling triggers (see previous post) since then the mass storage task will never start polling and only the write access will be affected by the slow accesses (timeouts) which should exclude any risks of pre-empting the mass storage task's polling operation.

This will not make the accesses faster since if the card is reporting that it is busy for half a second the writing task will need to wait but it will not block the overall system operation.


NXPTM M522XX, KINETIS and i.MX RT / Re: SD Task locking
« Last post by AlexS 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.
Pages: [1] 2 3 ... 10