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

Hi,

One thing to potentially check is your current setup with the single request setting. Right now you have .ignoresrc=false while using a DVL of 2 and a block size of 2.

Single requests are kind of opaque, but basically for the IADC, if a sample gets added to the fifo and the DMA is enabled, a single transfer request gets sent regardless of the DVL setting. In effect this means the DVL is ignored.

In the current LDMA descriptor, the block size is configured to to transfer two samples at a time. I'm wondering if these 0'd samples are occuring when the LDMA reads from an empty fifo.

What happens if the .ignoresrec is set to true, or if the block size is lowered to 1?

Best,

David

Hi,

I had to check the .pads layout file to find this, as it looks like the testpoints for EFM8 C2CK and C2D pins are not labelled on the silkscreen. From my view the testpoints look to be TP8 for C2CK and TP9 for C2D:

These test points look to be on the top right of the board, marked, where the test point marked "1" is TP8 and the one marked "2" is TP9:

If you try connecting through those, does it happen to work? Also for reference I got the board files from:

https://www.silabs.com/documents/public/schematic-files/efm8bb1lck-design-files.zip

Best,

David

Hey Tetsu,

Apologies for the delayed response. So for the WRSR I see what you mean now, and that does look correct.

For the debugger issue, thank you for providing logs. The error info for the getRegisterDataValue indicates, from my understanding, that there is the possibility for this to be a jlink debugger side issue. Do you have multiple SLSTK3701A boards that show the issue, and are these boards updated to the latest board firmware? Also what Jlink version are you using, viewable from the Jlink web control panel in a browser?

What is the output in the memory view of the debug window if you add a memory monitor for the QSPI periphieral memory region? My guess is that all the values are undefined but it would be good to confirm.

What happens if you try to read back a QSPI value to a watched global variable. IE:

uint32_t testvar

. . . 

    testvar = QSPI0->CONFIG;

Where testvar is added as a watch expression. Due to how peripheral access works this may succeed where the previous two methods of reading back the register value might fail. 

Best,

David

Hey Tetsu,

So for using the driver to enable QUADSPI mode, what I'd suggest is looking at SetQuadMode from the driver source used in that example if you haven't already:

/***************************************************************************//**
 * @brief Enable quad mode and high performance mode
 ******************************************************************************/
void MX25_SetQuadMode(void)
{
  uint8_t status;

  MX25_WREN();
  status = MX25_RDSR();
  while (!(status & MX25_STATUS_WEL)) {
    status = MX25_RDSR();
  }

  MX25_WRSR(status | MX25_STATUS_QE, 0, MX25_CONFIG2_LH);

  status = MX25_RDSR();
  while (!(status & MX25_STATUS_QE)) {
    status = MX25_RDSR();
  }
}

The part that sounds like it will need to be changed is the MX25_STATUS_QE bit. In the example this is set to bit 6 of the status register, but you can modify it to bit 1 in mx25r3235f.h (you can copy it into your project before modifying to avoid changing code in the SDK).

Regarding the debugger issue, this means that either studio or the debugger failed to read back the values in the device memory. This could potentially be an issue with the custom board, the debugger, connection to the host, or Studio itself. If you have other boards or evaluation kits to test, does this happen when using those or only this board. Also when debugging other projects on the same board, does the issue occur then as well. Finally, please capture your Studio logs when the debugging issue occurs (Help->Report Bug->Export log files). We may need to split off into the studio forums to get more information out of those, but having the logs early on will still be useful.

Best,

David