Using DSPI + Hardware serial input crashes my Max32...

Baltasar · **Joined:** Wed Oct 10, 2012 7:54 pm **Posts:** 4

Hi, just give me the test sketch you want me run and I tell you how it goes.

rasmadrak · **Posted:** Mon Oct 15, 2012 11:23 pm

Thanks!

Here's the simple test sketch that crashes everytime:

Code:

#include <DSPI.h>  //if commented out, this scetch runs without problems.

void setup() {                
  // initialize the digital pin as an output.
  // Pin 13 has an LED connected on most Arduino boards:
  pinMode(13, OUTPUT);     
  Serial.begin(115200);
}

void loop() {  
  if (Serial.available()) 
      Serial.println(Serial.read());  //crashpoint if DSPI.h is included. (read() crashes it )
  
  digitalWrite(13, HIGH);   // set the LED on
  delay(1000);              // wait for a second
  digitalWrite(13, LOW);    // set the LED off
  delay(1000);              // wait for a second
}

This is the example blink sketch with the added DSPI.h row and Serial rows.

Baltasar · **Joined:** Wed Oct 10, 2012 7:54 pm **Posts:** 4

Yap it crashes !!!

If I don't type anything + ENTER on the serial monitor window the led flashs ok, but as soon I type one single character... puff, green led stops.

I have to reset or power off and on again the board so the led starts blinking again.

I'm using the mpide-0023-windows-20120903 version.

rasmadrak · **Posted:** Tue Oct 16, 2012 8:38 pm

That's good (...) news!

Now I guess we need a little Digilent love to cure this bug...

Thanks for your time and help!

Calling Gene Apperson...

GeneApperson · **Posted:** Tue Oct 16, 2012 10:01 pm

Oops....

I hate it when people find bugs in my code

I'll look into it. If just including the library and not actually calling any of the functions is causing a problem, I'm thinking it may be some kind of interrupt conflict.

Gene Apperson
Digilent

GeneApperson · **Posted:** Tue Oct 16, 2012 10:46 pm

OK... I understand the problem.... fixing it is more problematic.

The problem comes in from the fact that the serial controllers in the MX5/6/7 devices are different than in the MX3/4 devices. In the MX3/4, there are separate serial controllers for UART and SPI ports. In the MX5/6/7 devices, the same serial controllers are used for both UARTs and SPI ports (& I2C ports).

In consequence of this, the UARTs and SPI ports on the Max32 share the same set of interrupt vectors. On the Uno32 they have different interrupt vectors. I developed the DSPI library on a Uno32, and clearly didn't test it enough on the Max32.

When you include the DSPI library, it installs a set of interrupt service routines for the same interrupt vectors as the HardwareSerial UARTs use. Since HardwareSerial uses interrupt driven I/O on the input side, what is probably happening is that the wrong ISR (the DSPI ISR) is actually receiving the interrupt. Since it hasn't been initialized, the system crashes.

If you're not using interrupt driven I/O for DSPI, you can work around the problem, by removing the definition for the DSPI ISRs at the bottom of DSPI.cpp. I just ran your example sketch. With the DSPI ISRs in place it crashes. After I removed the ISR definitions from DSPI.cpp, it no longer crashes. BTW: I didn't delete the ISR definitions, I just #ifdef'd them out. You could also just remove the ISR definition for the interrupt used by HardwareSerial object you are trying to use. The Serial object on the Max32 uses UART1, which conflicts with SPI3, which is used by DSPI2.

Unfortunately, to fix this properly is going to require implemeting an interrupt vector management subsystem in the core of the MPIDE runtime. This is something that I have been thinking about, and even started to implement several months ago, but got sidetracked onto other things. Clearly, I'm going to need to resurrect this and complete it.

I don't know how long this will take, but it will be a pretty major architectural change at the core of the system.

Gene Apperson
Digilent

mhanuel · **Joined:** Thu Jan 26, 2012 7:08 pm **Posts:** 6

Hello Gene,

I think this bug is nothing but new, just see viewtopic.php?f=7&t=928

I am using DSPI.h for replacing the SD2Card.cpp bit bang routines. I am not really sure whether or not I am using interrupt driven I/O. For example, to receive I just do data = spi.transfer(0xFF);

In any case, another workaround I have found that works for me so far is to move the vectors conflict to another peripheral in my case I am using Serial, Serial1 and Serial2 so I move DSPI3 vectors which conflicts with SPI4 which indeed points to UART2 vectors, I move to I2C2 vector.

Something like this on Board_Defs.h line 372.

#define _DSPI2_BASE _CAN1_BASE_ADDRESS//_SPI3_BASE_ADDRESS
#define _DSPI2_ERR_IRQ _CAN1_IRQ//_SPI3_ERR_IRQ
#define _DSPI2_RX_IRQ _CAN1_IRQ//_SPI3_RX_IRQ
#define _DSPI2_TX_IRQ _CAN1_IRQ//_SPI3_TX_IRQ
#define _DSPI2_VECTOR _CAN_1_VECTOR//_SPI_3_VECTOR
#define _DSPI2_IPL_ISR _CAN1_IPL_ISR//_SPI3_IPL_ISR
#define _DSPI2_IPL _CAN1_IPL_IPC//_SPI3_IPL_IPC
#define _DSPI2_SPL _CAN1_SPL_IPC //_SPI3_SPL_IPC

#define _DSPI3_BASE _I2C2A_BASE_ADDRESS //_SPI4_BASE_ADDRESS
#define _DSPI3_ERR_IRQ _I2C2A_ERR_IRQ //_SPI4_ERR_IRQ
#define _DSPI3_RX_IRQ _I2C2A_RX_IRQ //_SPI4_RX_IRQ
#define _DSPI3_TX_IRQ _I2C2A_TX_IRQ //_SPI4_TX_IRQ
#define _DSPI3_VECTOR _I2C_2_VECTOR //_SPI_4_VECTOR
#define _DSPI3_IPL_ISR _I2C2_IPL_ISR //_SPI4_IPL_ISR
#define _DSPI3_IPL _I2C2_IPL_IPC //_SPI4_IPL_IPC
#define _DSPI3_SPL _I2C2_SPL_IPC //_SPI4_SPL_IPC

I am not sure whether or not DSPI3 I/O interrupt works this way, since I am just using DSPI0.

I have some questions about this.

1. Can you explain me how to use interrupt driven I/O for DSPI.
2. Could you tell me if my workaround have some problem.

Thank you for reading,

rasmadrak · **Posted:** Wed Oct 17, 2012 9:41 am

Mhanuel -
Ah, I didn't see that this was a previously posted bug ( I did search for it beforehand).

As for interrupt driven transfer you enable/disable interrupts and use a specific interrupt transfer DSPI call. So using transfer() does not use interrupts, unless I'm misinformed.

Gene -
Thanks for your support and help!
I'll just disable the interrupts until further notice.

Sorry for pointing out the bug...

GeneApperson · **Posted:** Wed Oct 17, 2012 9:06 pm

Mhanuel

To use interrupt driven transfers with DSPI, you call the method enablIntTransfer to initialize for interrupt operation. Then you call the method intTransfer to begin a transfer. The transfer will occur in the background. You can call the method transCount to see if the transfer has completed. When transCount returns 0, all of the bytes have been transferred. You can call cancelTransfer to abort a transfer before it completes.

Your work around moves the conflicting interrupt service routines to other, non-conflicting, vectors. Doing it this way will also remove the conflict. Either removing the ISRs or changing them to different vectors will have the side effect of crashing the system if you try to do an interrupt driven transfer.

Using your method will also cause a conflict if you then try to use the peripherals whose vectors you have taken over (e.g. CAN1) and field interrupts for that peripheral. As long as you aren't trying to take interrupts from the other peripheral, though, there shouldn't be a problem.

rasmadrak,

You are correct, there are no interrupts involved when you use the transfer() method.

Sorry my code was causing problems. This is another of those constant reminders that I get of just how far short of perfect I am.

I'll get it fixed as soon as I can.

Gene

mhanuel · **Joined:** Thu Jan 26, 2012 7:08 pm **Posts:** 6

Gene,

Thank you for clarifying my doubts. (same for you rasmadrak).

Now I am more confident so that will not be a reason for my application to hang following your advice :roll:

Appreciated!

Using DSPI + Hardware serial input crashes my Max32...

Who is online