I'm not certain the token API will support this feature, just because you generally have a defined token ID and data format from what I have seen.

I think if you drop down a layer and write your own NVM3 objects with custom IDs, using nvm3_writeData(), that would be the best way to approach variable length data.

Pankaj.

Storing variable length strings should be supported for the same object ID, as you provide the length of each object during the write, and the latest write of an object itself is placed in a new area of the nvm3 instance on each update.

For an example of this, check out the nvm3_baremetal example in Studio (Launcher view->select EFR32xG starter kit from parts selector->Example projects). This example allows you to write to arbitrary object id's with a CLI. Updating an object with a string of a different length is supported. Example CLI output from example:
 

> write 0x01 string_length_short
Stored data at key 1
> read 0x01
Read data from key 1:
string_length_short
> write 0x01 string_length_but_longer
Stored data at key 1
> read 0x01
Read data from key 1:
string_length_but_longer

Additional Information on using CLI based examplse may be found here:
https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2018/08/28/using_virtual_compo-IYYh#:~:text=Introduction,debug%20messages%20from%20your%20application.

Hi Allen,

Ah, I think you are correct that the UART FIFO is the limiting factor here. In that case there are some more advanced descriptor configurations that could walk the array in the correct order, but I'm not sure it is worth the effort compared to just swapping order beforehand.

Just for future reference, I think a workable setup would be:

set LOOPCNT = array size - 1;

descriptor[0]:

• absolute src address
• halfword transfers
• decrements the source address
• xfercnt=2
• and starts at the second halfword address of the list\
• link to descriptor[1]

 This descriptor would transfer the first word in the array in reverse halfword order, setting the absolute src address value, and then link to the next descriptor.

descriptor[1]:

• relative src address
• halfword transfers
• decrements the source address
• xfercnt=2
• DECLOOPCNT=1
• link=0 (disabled)

The relative src address modifies whatever absolute src address was previously loaded, which will let you jump a full word down the array each transfer. The decrementing src address for each xfercnt will allow for the lower halfword to be sent first, then the upper. It also will enable looping, which lets you perform LOOPCNT transfers on the same descriptor, but then stop when LOOPCNT hits 0. This allows for more complex memory ordering operations like 2D copies, which is kind of similar to what is needed here. 

The link for the 2d copy example shows some code that is pretty similar, the only changes would be the transfer size (halfword), src address needing to decrement instead of incrementing like the default descriptor does, and the xfer size per descriptor.

Best,

David

Hi Rlkieth,

Generally there is some small leakage for leaving any pin enabled in sleep, but it should be on the order of tens of of nA. if the pin is logic high and it is consuming current I think the first thing to check is what the connection is on the RTS pin. Is the other end configured as open drain and does it have an internal pullup as well? 

For some context, Internally the BGX13S uses the same 41KOhm pullup as BGM13S devices if enabled. If your configuration has enabled the pullups, try disabling them when using an external pullup. Current draw through the internal pullup may be why raising the external pullup voltage to 3.4V resolved the issue. Commands for changing the internal pullup configuration may be found below.

https://docs.silabs.com/gecko-os/1/bgx/latest/commands#gdi

Best,

David

Hi Tom,

I'm not familiar with the FTDI solution, but I can say for our similar USB-UART bridge solutions, we have dedicated device drivers for our CP210x on mac and linux, and so these devices aren't actually CDC ACM class devices. I suspect there is a similar its a similar story for FTDI. This is done, at least for us, so we can use a lower-overhead protocol than the full CDC ACM spec.

For our MCU firmware examples though, I think by enumerating as a CDC ACM class device the naming on linux is always going to be ttyACMx based on the default udev rules. On Mac from a quick search it sounds like the name is assigned by the device driver for the given device, so I'm assuming this uxbmodemXXX is given by the MacOS default CDC ACM driver.

This enumeration as a CDC ACM class device is also how the device is going to be recognized by the given os's default CDC driver, so I don't think that this will be a problem for functionally getting serial communication over USB for either platform.

If you still need or want to test against your existing code that uses /dev/ttyUSBx, on linux I know that you can't actually reassign a device address once enumerated, but you can create a symbolic link to alias the address name. We have an existing article on how to do this for our USB-to-UART bridge devices, and similar logic should apply here:
https://www.silabs.com/community/interface/knowledge-base.entry.html/2016/06/06/fixed_tty_deviceass-XzTf

I don't think this is possible to change on mac without writing/modifying a driver.

Best,

David

Hi,

Thanks for providing the logs and source, from an initial look it looks like this might be due to the transfer size being set to halfwords while the I2S format is usartI2sFormatW32D32. Our ARM cores are little endian and I think that the default DESCRIPTOR_LINKREL_M2P_*'s are set up with that in mind.

I think that means the least significant halfword is sent first, but USART waits for 32 data bits before transmitting. I don't have the precise  interaction with the DOUBLE registers versus the normal 16 bit TX/RX registers here, but, since you are already reading and writing from the DOUBLE registers, I think you could just switch the ldma descriptors' transfer size to ldmaCtrlSizeWord (#129) and it hopefully should order things properly from there.

As for the SRC register change in the debugger, I'm not sure on why that is happening, the LDMA internals are a bit opaque to the user, but possibly it could be fetching the first sample internally and incrementing the pointer prior to actually receiving a trigger. It also could be that the USART TX FIFO is empty prior to it being enabled, maybe the first transfer is performed immediately?

Best,

David

Hi,

Thanks for providing the logs and source, from an initial look it looks like this might be due to the transfer size being set to halfwords while the I2S format is usartI2sFormatW32D32. Our ARM cores are little endian and I think that the default DESCRIPTOR_LINKREL_M2P_*'s are set up with that in mind.

I think that means the least significant halfword is sent first, but USART waits for 32 data bits before transmitting. I don't have the precise  interaction with the DOUBLE registers versus the normal 16 bit TX/RX registers here, but, since you are already reading and writing from the DOUBLE registers, I think you could just switch the ldma descriptors' transfer size to ldmaCtrlSizeWord (#96-101, #129-131) and it hopefully should order things properly from there.

As for the SRC register change in the debugger, I'm not sure on why that is happening, the LDMA internals are a bit opaque to the user, but possibly it could be fetching the first sample internally and incrementing the pointer prior to actually receiving a trigger. It also could be that the USART TX FIFO is empty prior to it being enabled, maybe the first transfer is performed immediately?

Best,

David

Hi,

Thanks for providing the logs and source, from an initial look it looks like this might be due to the transfer size being set to halfwords while the I2S format is usartI2sFormatW32D32. Our ARM cores are little endian and I think that the default DESCRIPTOR_LINKREL_M2P_*'s are set up with that in mind.

I think that means the least significant halfword is sent first, but USART waits for 32 data bits before transmitting. I don't have the precise  interaction with the DOUBLE registers versus the normal 16 bit TX/RX registers here, but, since you are already reading and writing from the DOUBLE registers, I think you could just switch the ldma descriptors' transfer size to ldmaCtrlSizeWord (#129) and it hopefully should order things properly from there.

As for the SRC register change in the debugger, I'm not sure on why that is happening, the LDMA internals are a bit opaque to the user, but possibly it could be fetching the first sample internally and incrementing the pointer prior to actually receiving a trigger. It also could be that the USART TX FIFO is empty prior to it being enabled, maybe the first transfer is performed immediately?

Best,

David

Hi,

Thanks for providing the logs and source, from an initial look it looks like this might be due to the transfer size being set to halfwords while the I2S format is usartI2sFormatW32D32. Our ARM cores are little endian and I think that the default DESCRIPTOR_LINKREL_M2P_*'s are set up with that in mind.

I think that means the least significant halfword is sent first, but USART waits for 32 data bits before transmitting. I don't have the precise  interaction with the DOUBLE registers versus the normal 16 bit TX/RX registers here, but, since you are already reading and writing from the DOUBLE registers, I think you could just switch the ldma descriptors' transfer size to ldmaCtrlSizeWord (#129) and it hopefully should order things properly from there.

As for the SRC register change in the debugger, I'm not sure on why that is happening, the LDMA internals are a bit opaque to the user, but possibly it could be fetching the first sample internally and incrementing the pointer prior to actually receiving a trigger. It also could be that the USART TX FIFO is empty prior to it being enabled, maybe the first transfer is performed immediately?

Best,

David

Hey Zeke,

The RXDATAV interrupt flag should be cleared by hardware when the USARTRX FIFO does not have any more data in it. 

Generally also, calling the NVIC clear method won't have much effect depending on the interrupt flag source. If it is a overflow RXDATAV, or error it will likely just immediately get re-asserted by the USART.

From your code, the likely problem is that your bufrx is filling with data before you even reach the serial_read method. At that point you are entering the else statement of your ISR, but as mentioned above the RXDATAV interrupt will get re-asserted.

You'll need to at minimum clear the USART1->IEN flags once your buffer fills to avoid the infinite ISR loop. But I don't think that would lead to the intended behavior (your buf would fill prior to serial_read). It is probably best to wait to enable the USART until your serial read method, and then disable it after the buf fills and before serial_read returns.

Best,

David