Hi,

The DMADRV_PeripheralMemory() method creates a single DMA transfer that starts at the base address of the buffer and increments for each word read from the ADC FIFO. 

So with your code snippet, the DMA will grab the next 10 samples from the ADC fifo before completing that transfer and trigger an LDMA interrupt. The ADC is configured to scan all inputs on each trigger in order, so the layout should be:

/// for a buffer declared as: uint32_t buffer[10];

buffer[0] = ch0 ADC sample @ t-10

buffer[1] = ch1 ADC sample @ t-10

buffer[2] = ch0 ADC sample @ t-9

buffer[3] = ch1 ADC sample @ t-9

...

buffer[8] = ch0 ADC sample @ t

buffer[9] = ch1 ADC sample @ t

DMADRV will then run your callback in that LDMA interrupt. Once the interrupt is completed the DMA will not run again until you call DMADRV_PeripheralMemory() again.

DMADRV_PeripheralMemory() doesn't store any state between transfers, so the next 10 samples will overwrite the buffer if DMADRV is called with the same buffer pointer.

DMADRV and the DMA don't know anything about the ADC configuration, or how the ADC is triggered. So in your case if you want to capture 10 samples from 2 channel in a single transfer, you'll need to tell the DMA to transfer 20 words total.

If you enable scanID, the layout of the 32bit word read from the ADC buffer will appear as follows depending on your declared format (RIGHT12 is default)

And you could pass a buffer of bitfield structs to DMADRV to be able to read back the ID easily.

struct adc_scan_sample
{
    unsigned id: 8
    unsigned _padding: 12
    unsigned sample: 12
}

For Question 2, the ADC can definitely be used in timer mode with the DMA. As mentioned above the DMA does not handle ADC triggering, so the ADC Timer can trigger transfers, while the DMA stores any new ADC results into a buffer. Note though that the DMA transfer needs to be active whenever the timer starts a transfer so that samples aren't lost. To do this you can either use a large buffer to store many scans while the timer is active, or use something similar to DMADRV_PeripheralMemoryPingPong() to have a DMA transfer that loops between two buffers without having to re-start the transfer in software.

Hi,

Are you looking for something with a simpler programming model, or something closer to the register accesses of the I2C peripheral. I ask as direct access to send ACK's etc. is mainly handled through the I2C state machine and interrupts.

If you are looking for the simplest possible programming model, we have an I2C simple polled mode SDK driver here:

https://docs.silabs.com/gecko-platform/latest/driver/api/group-i2cspm

For lower level register access, we don't have much in the form of example code, as em-lib is our supported programming interface to the I2C peripheral. The best bet is to view the emlib source code of the I2C_Transfer function, which can be found here:

https://github.com/SiliconLabs/sdk_support/blob/ff45be117a5a1a20d27296628b0632523f65c66a/platform/emlib/src/em_i2c.c#L504

Note that link is a static copy of SDK v2.7 and is not intended to be kept up to date.

The emlib peripheral examples are a middle ground here, showing the proper use of emlib.

Best,

David

I am using the following kits to transmit and receive data:

For transmission: 

Transmitter kit:  4010-DKPB868_BM  (Image attached)

Example code named:  rke_demo_2 (Available in the folder: Si4010_example_programs_.zip)

For Reception :  

Receiver kit: 4355-LED-868  (Image attached)

Code :  Custom code using a combination of  EZRADIO_SI4X55_1W_KEYFOB_DEMO (available in folder: Si4355_RCdemo_SW_.zip ) and  EzR_LCDBB_AESDemo (available in folder: EzR_LCDBB_AESDemo.zip)

I am sending data using rke_demo_2 and trying to receive the same on my receiver and transmit it further to PC using UART.

I am confused about how I can get data from receiver FIFO after successful reception.

Currently, I am able to receive the device id and button state by altering the radio.c file and transmit it to UART as I receive data but this is not a correct way to receive data.

I want to receive data from FIFO or any memory location where these data are stored. I am new in 4355 and unable to understand how to locate these locations.

Hi Lou-Ann,

The BGXpress Mobile Library contains the BGXpress Framework for both iOS and Android to help create mobile apps that can communicate with the BGX device.

The code can be found here: https://github.com/SiliconLabs/wireless-xpress

And the documentation can be found here: https://docs.silabs.com/gecko-os/1/bgxhost/framework/latest/index

Regards,
Dayoung

Hey Armin,

It might be a good idea to make a new thread for this, since it already shows up as answered in my feed and you may get more responses in a new thread.

That being said I'm not sure what those spikes could be, the most likely candidate in my mind is indeed that it is the ADC turning on the HFRCO in order to service the LDMA  request, as you suggested. However maybe the timing of these LDMA transfers is not occuring as you are expecting?

One trick that can help debug when the LDMA transfer occurs is to add a GPIO toggle descriptor that runs immediately after the triggered ADC LDMA descriptor. This would be for debugging only as you would not be able to run a descriptor with a transfer count larger than 1, but basically just for testing you would have:
 

// Pseudo-code snippet for ADC transfer with GPIO toggle

static uint32_t debug_mask = 1 << (DEBUG_PIN_NUMBER); // Set the bit corresponding to the debug pin

. . .

  // In GPIO initialization function

  CMU_ClockEnable(cmuClock_GPIO, true);
  GPIO_PinModeSet(DEBUG_PORT, DEBUG_PIN, gpioModePushPull, 1);

. . . 

  // In LDMA init
  static LDMA_Descriptor_t descList[] = {
    LDMA_DESCRIPTOR_LINKREL_P2M_WORD(&IADC0->SINGLEFIFODATA, scanBuffer0, 1, 1, // Stores a single sample and then moves to the next descriptor
    LDMA_DESCRIPTOR_LINKREL_M2M_BYTE(&debug_mask, &GPIO->P[CLOCK_SELECT_PORT].DOUTTGL, 1, -1) // Set debug pin low
  }
  
  descList[1].structReq=1 // Setting structReq=1 means that descriptor will run immediately, and won't wait for ADC trigger

. . .

If you trace that GPIO toggles, is the period the expected 130us?

Hi,

If possible, would you trace the debugger pins during the debugger connection event? checking if there is actually a voltage drop will help determine if this is some software error or an actual connection issue.

For some general ideas that could improve the stability of the debug connection, can you try to shorten the debugger connections to the board as much as possible, and additionally lower the debug clock speed? The articles linked below explain the max length and clock speed:

https://www.silabs.com/community/mcu/8-bit/knowledge-base.entry.html/2015/08/05/slowing_c2_clockspe-pwG4

https://www.silabs.com/community/mcu/8-bit/knowledge-base.entry.html/2015/08/05/c2_debugger_cablele-puhZ

Note that lowering the clock speed requires the legacy 8051 ide:

https://www.silabs.com/products/development-tools/software/8-bit-8051-microcontroller-software

Best,

David

Hi Armin,

Thanks for providing the code, it is very puzzling though where this extra LDMA request is coming from. Just to confirm, there is only a single call to LDMA_StartTransfer() in your LDMA Init, and this function is not called anywhere else in your code correct?

At least there is currently a workaround whatever the root cause is. I think the next step is for me to try to reproduce this behavior.

Best,

David

Hi Christopher,

Assuming all the physical connections are sound, the first thing to check is that the on-board debugger is not interfering here. Can you try disconnecting J10 and J11 to the left of the debug adapter chip. Alternatively in Studio, you can try connecting the on-board USB and disabling the on-board debug adapter in software. To do this follow the instructions linked below, but change to DEBUG IN mode rather than DEBUG OUT.

https://www.silabs.com/community/software/simplicity-studio/knowledge-base.entry.html/2016/10/07/simplicity_studiov4-FMQd

Best,

David

Hi Armin,

That is Interesting. So if DVL is set to 2 without single requests, then there is an 'extra' sample sitting in the ADC FIFO. If something unexpected is triggering the LDMA every 24th sample, then that extra sample will be consumed rather than an empty fifo read condition. This workaround should be sufficient so long as your application is ok with the buffers lagging by one ADC sample. 

As for what is causing this unexpected LDMA trigger, I'm not entirely sure. It does seem like it roughly corresponds with the frequency of interrupts. What does your LDMA ISR look like? Maybe there is something there.

Best,

David

Hey Armin,
 

Your configuration and understanding is correct, but by enabling single requests (ignoresrec = false) it allows for a LDMA trigger to be sent when one 16 bit sample is in the FIFO, even if your DVL=2.

This behavior is documented in section 26.3.4.1 reference manual:

26.3.4.1 Peripheral Transfer Requests

By default peripherals issue a Single Request (SREQ) when any data is present. For peripherals with a data buffer or FIFO this occurs any time the FIFO is not empty. Upon receiving an SREQ the LDMA will perform one DMA transfer and stop till another request is made. It is generally more efficient to wait for a peripheral to accumulate data and transfer in a burst. This both reduces overhead of the DMA engine and allows EM2 peripherals to save power by using the LDMA less often. To enable this set the IGNORESREQ bit in the LDMA_CHx_CTRL register (or descriptor) which will cause the LDMA to ignore SREQ's and wait for a full Request (REQ) signal. When the REQ is received the entire descriptor will be executed. For most peripherals with a FIFO the REQ signal is set when the FIFO is full, or a predetermined threshold has been reached. See the individual peripheral chapters for more information.

And that "predetermined threshold" mentioned is the DVL of the ADC FIFO here.

Once you set ignoresrec=true. You should be able to safely use a block size of 2.

Best,

David