TWIM EasyDMA Delay Between Bytes

RE: TWIM EasyDMA Delay Between Bytes

snoopy20 — Tue, 15 Dec 2020 23:02:45 GMT

All working. :)

A LCD 2004 (etc) driver is coming to NRF52 on github soon.

RE: TWIM EasyDMA Delay Between Bytes

snoopy20 — Tue, 15 Dec 2020 12:52:13 GMT

Yup that's got it! Right, cooking with gas now. Thanks!

RE: TWIM EasyDMA Delay Between Bytes

haakonsh — Tue, 15 Dec 2020 12:51:05 GMT

Yes!

If you don't need the interrupt you can disable it, the event will still function.

RE: TWIM EasyDMA Delay Between Bytes

snoopy20 — Tue, 15 Dec 2020 12:49:42 GMT

Oh, when EVENTS_COMPARE[X] fires it must be cleared in software for the interrupt, but for the PPI it's a single pulse?

RE: TWIM EasyDMA Delay Between Bytes

snoopy20 — Tue, 15 Dec 2020 12:47:18 GMT

TIMER4 in counter mode. TIMER3 for the spacing.

The interrupt fires and continues to fire, I'm unable to shut it down.

Even when in the interrupt I do

  CFG_TIMER_LCD_SPACE->TASKS_STOP = 1;
  CFG_TIMER_LCD_COUNTER->TASKS_STOP = 1;
  CFG_TIMER_LCD_COUNTER->TASKS_CLEAR = 1;
  CFG_TIMER_LCD_COUNTER->CC[0] = 900;

The PPI should have already stopped TIMER3 and cleared TIMER4 but the above would ensure it. Weirdly the interrupt continues!

RE: TWIM EasyDMA Delay Between Bytes

haakonsh — Tue, 15 Dec 2020 12:30:02 GMT

Can you read out the registers of the PPI channel you're using?

Which timer instance are you using?

RE: TWIM EasyDMA Delay Between Bytes

snoopy20 — Tue, 15 Dec 2020 12:26:54 GMT

Yupp, just done that and still no-go. What's odd is the interrupt on the same compare is firing, so that side is good, it's just not making it's way through PPI.

NRF_PPI->CH[CFG_PPI_LCD_CHANNEL_COUNTER_RESET].EEP = (uint32_t) &CFG_TIMER_LCD_COUNTER->EVENTS_COMPARE[0]; // wire timer compare
NRF_PPI->CH[CFG_PPI_LCD_CHANNEL_COUNTER_RESET].TEP = (uint32_t) &CFG_TIMER_LCD_SPACE->TASKS_STOP;
NRF_PPI->FORK[CFG_PPI_LCD_CHANNEL_COUNTER_RESET].TEP = (uint32_t) &CFG_TIMER_LCD_SPACE->TASKS_CLEAR;

To confirm when in COUNTER mode there's no means to stop the timer (TASK_START) doesn't need to be set? This potentially means the compare is always active and if so I''ll need to disable the interrupt (could be why it's refiring).

RE: TWIM EasyDMA Delay Between Bytes

haakonsh — Tue, 15 Dec 2020 12:25:26 GMT

[quote user="snoopy20"] I'm wondering if by having a short on the compare (to stop and reset) that prevents the event reaching the PPI?[/quote]

Not that I'm aware of, you should still get a COMPARE event event though you shorted it to the STOP and CLEAR tasks. You can try to disable one of the shorts and see if that changes anything.

RE: TWIM EasyDMA Delay Between Bytes

snoopy20 — Tue, 15 Dec 2020 12:21:15 GMT

Moving back, I have an issue that the PPI isn't stopping the first timer. I'm wondering if by having a short on the compare (to stop and reset) that prevents the event reaching the PPI?

RE: TWIM EasyDMA Delay Between Bytes

snoopy20 — Tue, 15 Dec 2020 12:18:24 GMT

The same has occurred with a SAMD project so seems to be a SEGGER issue, or setting I'm not aware of.

RE: TWIM EasyDMA Delay Between Bytes

haakonsh — Tue, 15 Dec 2020 11:22:20 GMT

Not sure if our licenses covers c++ for ses

RE: TWIM EasyDMA Delay Between Bytes

snoopy20 — Tue, 15 Dec 2020 10:06:59 GMT

It seems to be the default with segger embedded. I tried a fresh basic project with the same result.

RE: TWIM EasyDMA Delay Between Bytes

haakonsh — Tue, 15 Dec 2020 07:14:46 GMT

Aah, I'm not that familiar with c++, but I'd venture to guess that your build system should support a c++ based main if configured properly. Maybe you need to modify the linker or something.

RE: TWIM EasyDMA Delay Between Bytes

snoopy20 — Mon, 14 Dec 2020 23:24:10 GMT

Finally figured it, if main.c is main.cpp no interrupt work!

RE: TWIM EasyDMA Delay Between Bytes

snoopy20 — Mon, 14 Dec 2020 23:22:26 GMT

I've determined that no interrupt handler is hit. I thought these were picked up by ses_startup_nrf52.c and can't see any other reason why they're being ignored.

RE: TWIM EasyDMA Delay Between Bytes

snoopy20 — Mon, 14 Dec 2020 14:30:46 GMT

I have the approach sorted - two timers, three PPI channels and a TWIM.

The problem and I've yet to crack it is as soon as the counter compare event is one and the interrupt fires the CPU appears to lock (I am not in any interrupt or loop).

#define CFG_PIN_LCD_SDA 5
#define CFG_PIN_LCD_SCL 6
#define CFG_PIN_LCD_VDD 7

#define CFG_PPI_LCD_CHANNEL_TWIM_START 2
#define CFG_PPI_LCD_CHANNEL_COUNTER_TICK 3
#define CFG_PPI_LCD_CHANNEL_COUNTER_RESET 4
#define CFG_TIMER_LCD_SPACE NRF_TIMER3
#define CFG_TIMER_LCD_COUNTER NRF_TIMER4
#define CFG_TWIM_LCD_TX NRF_TWIM0

Been over and over the config below. It looks perfect to my eyes.

  NRF_GPIO->PIN_CNF[CFG_PIN_LCD_SCL] = I2C_PIN_INIT_CONF;
  NRF_GPIO->PIN_CNF[CFG_PIN_LCD_SDA] = I2C_PIN_INIT_CONF;
  NRF_GPIO->PIN_CNF[CFG_PIN_LCD_VDD] = ((GPIO_PIN_CNF_SENSE_Disabled << GPIO_PIN_CNF_SENSE_Pos) | (GPIO_PIN_CNF_DRIVE_S0S1 << GPIO_PIN_CNF_DRIVE_Pos) | (GPIO_PIN_CNF_INPUT_Disconnect << GPIO_PIN_CNF_INPUT_Pos) | (GPIO_PIN_CNF_DIR_Output << GPIO_PIN_CNF_DIR_Pos));
  NRF_GPIO->OUTSET = 1 << CFG_PIN_LCD_VDD;

  CFG_TIMER_LCD_SPACE->PRESCALER = 0;
  CFG_TIMER_LCD_SPACE->CC[0] = 1;
  CFG_TIMER_LCD_SPACE->CC[1] = LCD_TICKS_BETWEEN_DATA - 50U;
  CFG_TIMER_LCD_SPACE->CC[2] = LCD_TICKS_BETWEEN_DATA;
  CFG_TIMER_LCD_SPACE->SHORTS = TIMER_SHORTS_COMPARE2_CLEAR_Enabled << TIMER_SHORTS_COMPARE2_CLEAR_Pos;
  CFG_TIMER_LCD_COUNTER->PRESCALER = 0;
  CFG_TIMER_LCD_COUNTER->MODE = TIMER_MODE_MODE_LowPowerCounter << TIMER_MODE_MODE_Pos;
  CFG_TIMER_LCD_COUNTER->SHORTS = TIMER_SHORTS_COMPARE0_CLEAR_Enabled << TIMER_SHORTS_COMPARE0_CLEAR_Pos;
  CFG_TIMER_LCD_COUNTER->INTENSET = TIMER_INTENSET_COMPARE0_Enabled << TIMER_INTENSET_COMPARE0_Pos;
  CFG_TIMER_LCD_COUNTER->TASKS_START = 1;
  
  CFG_TWIM_LCD_TX->ADDRESS = 0x3f;
  CFG_TWIM_LCD_TX->FREQUENCY = TWIM_FREQUENCY_FREQUENCY_K100 << TWIM_FREQUENCY_FREQUENCY_Pos;
  CFG_TWIM_LCD_TX->PSEL.SCL = (TWIM_PSEL_SCL_CONNECT_Connected << TWIM_PSEL_SCL_CONNECT_Pos) | CFG_PIN_LCD_SCL;
  CFG_TWIM_LCD_TX->PSEL.SDA = (TWIM_PSEL_SDA_CONNECT_Connected << TWIM_PSEL_SDA_CONNECT_Pos) | CFG_PIN_LCD_SDA;
  CFG_TWIM_LCD_TX->SHORTS = TWIM_SHORTS_LASTTX_STOP_Enabled << TWIM_SHORTS_LASTTX_STOP_Pos;
  CFG_TWIM_LCD_TX->TXD.LIST = TWIM_TXD_LIST_LIST_ArrayList << TWIM_TXD_LIST_LIST_Pos;
  CFG_TWIM_LCD_TX->TXD.MAXCNT = LCD_PAYLOAD_CMD_DATA;
  CFG_TWIM_LCD_TX->ENABLE = TWIM_ENABLE_ENABLE_Enabled << TWIM_ENABLE_ENABLE_Pos;

  //NRF_PPI->CH[CFG_PPI_LCD_CHANNEL_TWIM_START].EEP = (uint32_t) &CFG_TIMER_LCD_SPACE->EVENTS_COMPARE[0]; // wire timer compare
  //NRF_PPI->CH[CFG_PPI_LCD_CHANNEL_TWIM_START].TEP = (uint32_t) &CFG_TWIM_LCD_TX->TASKS_STARTTX; 
  NRF_PPI->CH[CFG_PPI_LCD_CHANNEL_COUNTER_TICK].EEP = (uint32_t) &CFG_TIMER_LCD_SPACE->EVENTS_COMPARE[1]; // wire timer compare
  NRF_PPI->CH[CFG_PPI_LCD_CHANNEL_COUNTER_TICK].TEP = (uint32_t) &CFG_TIMER_LCD_COUNTER->TASKS_COUNT; 
  NRF_PPI->CH[CFG_PPI_LCD_CHANNEL_COUNTER_RESET].EEP = (uint32_t) &CFG_TIMER_LCD_COUNTER->EVENTS_COMPARE[0]; // wire timer compare
  NRF_PPI->CH[CFG_PPI_LCD_CHANNEL_COUNTER_RESET].TEP = (uint32_t) &CFG_TIMER_LCD_SPACE->TASKS_STOP;
  NRF_PPI->FORK[CFG_PPI_LCD_CHANNEL_COUNTER_RESET].TEP = (uint32_t) &CFG_TIMER_LCD_SPACE->TASKS_CLEAR;

  NRF_PPI->CHENSET = 1 << CFG_PPI_LCD_CHANNEL_TWIM_START | 1 << CFG_PPI_LCD_CHANNEL_COUNTER_TICK | 1 << CFG_PPI_LCD_CHANNEL_COUNTER_RESET;  // enable ppi channel

  NVIC_EnableIRQ(TIMER4_IRQn);

   __enable_irq();

printf is working, stuck in the interrupt since can''t break inside of it. It doesn't hit.

void TIMER4_IRQHandler (void) {

  printf("hurrah", 0);
  dmaBuffer.transferBuffer->size = 0;
  dmaBuffer.transferBuffer = getNextBuffer(dmaBuffer.transferBuffer);
  dmaBuffer.writing = 0;
  if (!dmaBuffer.locked && dmaBuffer.transferBuffer->size) {
    __startTransfer();
  }
}

RE: TWIM EasyDMA Delay Between Bytes

haakonsh — Mon, 14 Dec 2020 14:05:58 GMT

[quote user=""]My question then is around EasyDMA List mode. Can I clarify that what it's doing is adding MAXCNT to the PTR object after each send?

In other words if I set MAXCNT = 1 and use list mode I should get the spaces inbetween the bytes without needing to interrupt to PTR++?[/quote]

Yes, but I believe each byte will be a new transfer, so a new address+R/W-bit and 1 byte data for each iteration, but I'm not quite sure. I guess you'll have to try and see if it works.