Problem of SYS/BIOS integrated with uDma interrupt on Concerto

LINHU YING

Other Parts Discussed in Thread: SYSBIOS

Hi, TI experts:

Now I'm working on TI F28M35 Concerto Microcontroller, I have developed a program of uDma interrupt test on the M3 part of Concerto and it works well. But Now I want to integrate this program on SYS/BIOS RTOS, but I couldn't make it run correctly. the verson of my SYS/BIOS is 6.33.4.39. XDC tool 3.23.3.53.

My aim is to write 512 data into original data buffer and transfer it to the destination buffer. The data transfer is between shared rams. When the data buffer finished, it will generate a uDma interrupt and call the myIsr routine while incresing DMACount which indicates the interrupt occurs. Here is my program:

#include <xdc/std.h>
#include <xdc/runtime/Log.h>
#include <ti/sysbios/BIOS.h>
#include <xdc/runtime/System.h>
#include <ti/sysbios/knl/Task.h>
#include <ti/sysbios/family/arm/m3/Hwi.h>

#include "inc/hw_ints.h"
#include "inc/hw_memmap.h"
#include "inc/hw_nvic.h"
#include "inc/hw_types.h"
#include "inc/hw_sysctl.h"
#include "inc/hw_uart.h"
#include "inc/hw_epi.h"
#include "inc/hw_gpio.h"
#include "inc/hw_ram.h"
#include "driverlib/gpio.h"
#include "driverlib/ram.h"
#include "driverlib/sysctl.h"
#include "driverlib/systick.h"
#include "driverlib/uart.h"
#include "driverlib/udma.h"
#include "driverlib/interrupt.h"
#include "driverlib/ipc.h"
#include "utils/cpu_usage.h"
#include "utils/ustdlib.h"
#include "driverlib/debug.h"
#include "driverlib/epi.h"
#include "driverlib/timer.h"

#define MEM_BUFFER_SIZE 512

int DMACount = 0;

#pragma DATA_SECTION(g_ulSrcBuf, ".g_ulSrcBuf");
#pragma DATA_SECTION(g_ulDstBuf, ".g_ulDstBuf");

static double g_ulSrcBuf[MEM_BUFFER_SIZE];
static double g_ulDstBuf[MEM_BUFFER_SIZE];

#pragma DATA_ALIGN(ucControlTable, 512)
unsigned char ucControlTable[512];

#ifdef DEBUG
void
__error__(char *pcFilename, unsigned long ulLine)
{
}

#endif

void
WriteDataSrc(void)
{

// write data into the buffer
   unsigned int Idx;
   double *Src_add = (double *)0x20008000;
   for(Idx=0;Idx<512;Idx++){
       *Src_add = Idx;
       Src_add ++;
   }

}

/*
* ======== myIsr ========
* Interrupt service routine for the uDma interrupts.
*/
void myIsr()
{
    Log_info0("Executing in myIsr for uDma interrupt");
    DMACount ++;
}

Void myTaskFxn()
{

    Log_info0("Executing in my Task");
    WriteDataSrc();

    // Put the attributes in a known state for the uDMA software channel.
    // These should already be disabled by default.
    uDMAChannelAttributeDisable(UDMA_CHANNEL_SW_30,
                                UDMA_ATTR_USEBURST | UDMA_ATTR_ALTSELECT |
                                UDMA_ATTR_HIGH_PRIORITY | UDMA_ATTR_REQMASK);

    // Configure the control parameters for the SW channel. The SW channel
    // will be used to transfer between two memory buffers, 32 bits at a time.
    // Therefore the data size is 32 bits, and the address increment is 32 bits
    // for both source and destination. The arbitration size will be set to 8,
    // which causes the uDMA controller to rearbitrate after 8 items are
    // transferred. This keeps this channel from hogging the uDMA controller
    // once the transfer is started, and allows other channels cycles if they
    // are higher priority.
    uDMAChannelControlSet(UDMA_CHANNEL_SW_30 | UDMA_PRI_SELECT,
                          UDMA_SIZE_32 | UDMA_SRC_INC_32 | UDMA_DST_INC_32 |
                          UDMA_ARB_8);

    // Set up the transfer parameters for the software channel. This will
    // configure the transfer buffers and the transfer size. Auto mode must be
    // used for software transfers.
    uDMAChannelTransferSet(UDMA_CHANNEL_SW_30 | UDMA_PRI_SELECT, UDMA_MODE_AUTO,
                           g_ulSrcBuf, g_ulDstBuf, MEM_BUFFER_SIZE);

    // Now the software channel is primed to start a transfer. The channel
    // must be enabled. For software based transfers, a request must be
    // issued. After this, the uDMA memory transfer begins.
    uDMAChannelEnable(UDMA_CHANNEL_SW_30);
    uDMAChannelRequest(UDMA_CHANNEL_SW_30);

}

/*
* ======== main ========
*/
Int main(Int argc, Char* argv[])
{
   //System initializing
    SysCtlClockConfigSet(SYSCTL_USE_PLL | (SYSCTL_SPLLIMULT_M & 0xF) |
                         SYSCTL_SYSDIV_1 | SYSCTL_M3SSDIV_2 |
                         SYSCTL_XCLKDIV_4);

    HWREG(SYSCTL_MWRALLOW) = 0xA5A5A5A5;

    SysCtlPeripheralClockGating(true);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_UDMA);
    SysCtlPeripheralSleepEnable(SYSCTL_PERIPH_UDMA);

//**************************uDMA***********************************

    // Enable the uDMA controller.
    uDMAEnable();

    // Point at the control table to use for channel control structures.
    uDMAControlBaseSet(ucControlTable);

//********************Interrupt**********************************

    // Enable and register the DMA interrupt.
    IntEnable(INT_UDMA);

    // Enable all processor interrupts.
    IntMasterEnable();
//********************Interrupt**********************************


    BIOS_start();
}

Here is the my cfg file:

var Defaults = xdc.useModule('xdc.runtime.Defaults');
var Diags = xdc.useModule('xdc.runtime.Diags');
var Log = xdc.useModule('xdc.runtime.Log');
var LoggerBuf = xdc.useModule('xdc.runtime.LoggerBuf');
var Main = xdc.useModule('xdc.runtime.Main');
var Text = xdc.useModule('xdc.runtime.Text');
var BIOS = xdc.useModule('ti.sysbios.BIOS');
var Hwi = xdc.useModule('ti.sysbios.family.arm.m3.Hwi');
var Task = xdc.useModule("ti.sysbios.knl.Task");
var System = xdc.useModule('xdc.runtime.System');

/* Create a task with priority 2 */
var taskParams = new Task.Params();
taskParams.priority = 2;
var myTask = Task.create('&myTaskFxn', taskParams);

/*
* Create a LoggerBuf and make it the default logger for all modules.
*/
var LoggerBufParams = new LoggerBuf.Params();
LoggerBufParams.numEntries = 16;
var logger0 = LoggerBuf.create(LoggerBufParams);
Defaults.common$.logger = logger0;

Main.common$.diags_INFO = Diags.ALWAYS_ON;

Program.stack = 0x100;

/* NVIC Interrupt */
var interruptNum = 62;
var hwiParams = new Hwi.Params();
hwiParams.arg = interruptNum;
hwiParams.priority = 5;
Hwi.create(interruptNum, "&myIsr", hwiParams);

/*
* Build a custom BIOS library. The custom library will be smaller than the
* pre-built "instrumented" (default) and "non-instrumented" libraries.
*
* The BIOS.logsEnabled parameter specifies whether the Logging is enabled
* within BIOS for this custom build. These logs are used by the RTA and
* UIA analysis tools.
*
* The BIOS.assertsEnabled parameter specifies whether BIOS code will
* include Assert() checks. Setting this parameter to 'false' will generate
* smaller and faster code, but having asserts enabled is recommended for
* early development as the Assert() checks will catch lots of programming
* errors (invalid parameters, etc.)
*/
BIOS.libType = BIOS.LibType_Custom;
BIOS.logsEnabled = false;
BIOS.assertsEnabled = true;

I lanch the program on microprocessor, the dma transfer and interrupt do not work. The DMACount = 0 and the destination buffer is 0

but if I cancell this two lines of code
#pragma DATA_SECTION(g_ulSrcBuf, ".g_ulSrcBuf");
#pragma DATA_SECTION(g_ulDstBuf, ".g_ulDstBuf");

which means I let the compiler automatically assigned memory space for the original and destination buffer data array. In this case I relanch the program, the DMACount = 1 which means uDma interrupt works but the destination buffer is still 0. It's very strange that the uDma interrupt works but the data transfer not working. I'm new with SYS/BIOS, so I hope you guys could give me some useful suggestions.

Thanks!

Lin

over 13 years ago

0 MarkGrosen over 13 years ago

TI__Expert 4125 points

Lin,

A few ideas to consider:

1. The uDMA control table requires 1024-byte alignment

#pragma DATA_ALIGN(ucControlTable, 512)
unsigned char ucControlTable[512];

2. The writeDataSrc has a hard-coded address - are you sure this corresponds to the actual buffer address?

double *Src_add = (double *)0x20008000;
for(Idx=0;Idx<512;Idx++){

3. You should not enable CPU interrupts in main() - this is done by SYS/BIOS at the appropriate time as part of the BIOS_start() function:

// Enable all processor interrupts.
    IntMasterEnable();
//********************Interrupt**********************************


    BIOS_start();

Mark

0 LINHU YING over 13 years ago in reply to MarkGrosen

Prodigy 135 points

Hi, mark:

Firstly thanks for your quickly reply. I followed your advices, changed the uDma control table into 1024 bytes and cancelled IntMasterEnable() function, and make sure that physical address of data buffer is corresponed to that in code. But it doesn't work though. Here is the some symptoms maybe could help you to find the problem:

Here is the original data buffer, you could see that the program writes 1024 data into g_ulSrcBuf array.

Then I lanched the program, you can see the DMACount is refreshed and equal to 1 and the records in log file, means that the interrupt routine has been triggered

But at the end I check the destination data buffer, there are nothing on it.

Any other suggestions?

Regards!

Lin

0 Tom Kopriva over 13 years ago in reply to LINHU YING

TI__Mastermind 20480 points

Hi Lin,

Check your destination buffer placement. It lies in a memory segment that isn't accessible to the uDMA.

0 MarkGrosen over 13 years ago in reply to Tom Kopriva

TI__Expert 4125 points

After changing the buffer locations to be in uDMA-accessible memory, the transfers and interrupts worked in my example.

I noticed another potential problem in your code: the transfer count refers to transfers that are the size of the values set in the call to:

uDMAChannelControlSet(UDMA_CHANNEL_SW | UDMA_PRI_SELECT,
UDMA_SIZE_32 | UDMA_SRC_INC_32 | UDMA_DST_INC_32 |
UDMA_ARB_8);

Note these are 32-bits, so the transfers will be 4-bytes. Your src and dst buffers are "double" which is 8 bytes on M3, so you will only transfer half the buffer.

Mark

0 LINHU YING over 13 years ago in reply to Tom Kopriva

Prodigy 135 points

Thanks for your advises, I haven't noticed that problem.

I orginally ditributed the memory space for original and destination buffer, I allocated S0 for g_ulSrcBuf and S1 for g_ulDstBuf and transfer data from S0 to S1 by adding two lines into my code:

#pragma DATA_SECTION(g_ulSrcBuf, ".g_ulSrcBuf");
#pragma DATA_SECTION(g_ulDstBuf, ".g_ulDstBuf");

and here is my related .cmd file:

* ======== F28M35H52C1.cmd ========
* Define the memory block start/length for the F28M35H52C1 M3
*/

MEMORY
{
    FLASH_BOOT (RWX): origin = 0x200030,   length = 0x4
    FLASH (RWX)     : origin = 0x200034,   length = 0x7FF9C
    C03SRAM (RWX)   : origin = 0x20000000, length = 0x8000
    DataSrc (RWX)   : origin = 0x20008000, length = 0x2000
    DataDst (RWX)   : origin = 0x2000A000, length = 0x2000
    S07SHRAM (RWX) : origin = 0x2000C000, length = 0xC000
    CTOMMSGRAM (R) : origin = 0x2007F000, length = 0x800
    MTOCMSGRAM (RW) : origin = 0x2007F800, length = 0x800
}

SECTIONS
{
    /* Allocate program areas: */

    .text       : > FLASH
    .cinit      : > FLASH
    .pinit      : > FLASH
    .init_array : > FLASH

    /* Initalized sections go in Flash */
    .const      : > FLASH

    /* Allocate uninitalized data sections: */
    .intvecs:   > C03SRAM
    .resetisr: > C03SRAM
    .vtable     : > C03SRAM
    .data       : > C03SRAM
    .bss        : > C03SRAM
    .sysmem     : > C03SRAM
    .stack      : > C03SRAM
    .cio        : > C03SRAM
    .neardata   : > C03SRAM
    .rodata     : > C03SRAM
    .args       : > C03SRAM
    .g_ulSrcBuf : > DataSrc
    .g_ulDstBuf : > DataDst

}

__STACK_TOP = __stack + 256;

But unfortunately in this case even the interrupt couldn't be triggered.

So I decided to let the complier automatically allocate the memory space for these two buffers ( by cancelling the code #pragma DATA_SECTION(g_ulSrcBuf, ".g_ulSrcBuf"); #pragma DATA_SECTION(g_ulDstBuf, ".g_ulDstBuf"); ), at least the interrupt is triggered in this case, but I haven't considered that the compiler allocate the buffer automatically into a memory space where uDma couldn't visit.

Where I have made the mistake?

0 Tom Kopriva over 13 years ago in reply to LINHU YING

TI__Mastermind 20480 points

Hi Linhu,

keep in mind you are using SYS/BIOS. It handles its own interrupt vector table. You shouldn't need a .intvecs or .resetisr code section here...

Use a linker cmd file that you would get from new CCS project wizard F28M35H52C1 project. Modify that linker cmd file to allocate your buffers for the uDMA in S07SHRAM.

For example:

MEMORY
{
    FLASH_BOOT (RWX): origin = 0x200030,   length = 0x4
    FLASH (RWX)     : origin = 0x200034,   length = 0x7FF9C
    C03SRAM (RWX)   : origin = 0x20000000, length = 0x8000
    S07SHRAM (RWX) : origin = 0x20008000, length = 0x10000
    CTOMMSGRAM (R) : origin = 0x2007F000, length = 0x800
    MTOCMSGRAM (RW) : origin = 0x2007F800, length = 0x800
}

SECTIONS
{
    /* Allocate program areas: */
    .text       : > FLASH
    .cinit      : > FLASH
    .pinit      : > FLASH
    .init_array : > FLASH

    /* Initalized sections go in Flash */
    .const      : > FLASH

    /* Allocate uninitalized data sections: */
    .data       : > C03SRAM
    .bss        : > C03SRAM
    .sysmem     : > C03SRAM
    .stack      : > C03SRAM
    .cio        : > C03SRAM
    .neardata   : > C03SRAM
    .rodata     : > C03SRAM
    .args       : > C03SRAM
    .g_ulSrcBuf : > S07SHRAM
    .g_ulDstBuf : > S07SHRAM

}

__STACK_TOP = __stack + 256;

If you are getting an link error due to g_pfnRAMVectors not being found, you will need to rebuild the driverlib (v140) with RTOS_SUPPLIED_INTERRUPTS predefined.

0 LINHU YING over 13 years ago in reply to Tom Kopriva

Prodigy 135 points

Hi, Tom:

I followed your advice and changed the cmd file. When I recompile the project, occured the problem " unresolved symbol g_pfnVectors, first referenced in ../driverlib.lib<interrupt.obj> " as you said. And I added definition of RTOS_SUPPLIED_INTERRUPTS , I could compile the program successfully. But the problem is not resolved yet. If I cancelled "#pragma DATA_SECTION(g_ulSrcBuf, ".g_ulSrcBuf"); and #pragma DATA_SECTION(g_ulDstBuf, ".g_ulDstBuf"); " , then uDma interrupt works. So I think the problem is related to the cmd file.

I'm really confused that. Does TI have some tutorials about explaining how to modify your cmd file in the environment of Sys/Bios? Thanks!

Lin

0 Tom Kopriva over 13 years ago in reply to LINHU YING

TI__Mastermind 20480 points

Hi Linhu,

Can you see whether .g_ulSrcBuf, .g_ulDstBuf, and ucControlTable[] are in DMA accessible memory sections in your .map file?

If the variables are placed in the correct sections, then your linker cmd file is OK ruling it out as the source of the problem.

The DMA interrupts kick in after if finishes a DMA transfer. In the case when you are using a destination buffer that isn't accessible to the DMA, it just silently fails and generates the interrupts (as it probably should). When you are using a correct destination location, the DMA may be running into a different problem (perhaps with the configuration) and hence never gets started...(I'm guessing here).

Can you verify that that data was actually copied from the source to the destination?

This should verify if the data was actually copied. If it still wasn't, then the problem probably lies in the DMA configuration. If it is in the DMA configuration I would check with the settings Marc mention, since he was able to get it to work.

0 LINHU YING over 13 years ago in reply to Tom Kopriva

Prodigy 135 points

Hi Tom,

Firstly I don't really think the configuration of uDma could cause this problem. Because I have used this program without SYS/BIOS and it works well. So you mean that I have to modify the configuration of uDma to adapt the SYS/BIOS environment?

Then I try to explain to you what happened in my program. Origianlly I have allocate .g_ulSrcBuf and .g_ulDstBuf manually by adding ".g_ulSrcBuf >S07SHRAM" and ".g_ulDstBuf >S07SHRAM" into my cmd file. In this case the udma transfer would not be actived and the interrupt routine could not be kicked neither.

Here is the physical address of .g_ulSrcBuf(0x2000A000) and .g_ulDstBuf (0x2000A000), located in shared ram where could be accessible by uDma

After lanch the program, you could see the data in .g_ulSrcBuf, but all 0 in .g_ulDstBuf. The dma count remains 0.

And it's very strange that I couldn not found the .u_glSrcBuf and .g_ulDstBuf variables in the memory window.

Then I tried to let the complier allocate the address for .g_ulSrcBuf and .g_ulDstBuf automatically by cancelling these 2 lines of code:

#pragma DATA_SECTION(g_ulSrcBuf, ".g_ulSrcBuf");
#pragma DATA_SECTION(g_ulDstBuf, ".g_ulDstBuf");

you could see that the address of .g_ulSrcBuf(0x20002400) and .g_ulDstBuf(0x20000400). These address are distributed automatically by the compiler which I could not control.

But when I lanch the program in this case, you could see that the DMACount is 1 means that the interrupt routine is triggered. I think in this case the uDma transfer is actived and excuted successfully. Just because of the address of .g_ulDstBuf located by compiler in the area where is not accessible by uDma, then uDma couln't write the data into the .g_ulDstBuf . You could see the data in .g_ulDstBuf remains 0.

I have no idea what could cause these strange problems. What do you think?

Lin

0 Oltan DOCI over 13 years ago in reply to LINHU YING

Prodigy 40 points

Hi LINHU YING,

I'm using CCSv5 with SYS/BIOS and I have also problems with HWI concerning the UART.

When I look to your interrupt number that you have specified in your .cfg file I see 62 and in the Concerto TechnicalReference_spruh22b this interrupt vector is "Reserved" (see page 114). The DMAs 1,2,3,4,5,6 are in the interrupt vectors 80 to 85.

I use the UART so the RX and TX SCI-A (interrupt numbers 96 and 97) and it doesn't work.

I don't undersand because with DSP/BIOS under CCSv4 it works very well !

Any idea ?

Regards

0 LINHU YING over 13 years ago in reply to Oltan DOCI

Prodigy 135 points

Hi, Oltan:

I'm currently using CCSV4.2, I can't make it work too......

Thanks for your advice, I think you mean that the dma interrupt vectors on C28x core of Concerto are from 80-85. But I'm using Cortex M3 Core now, of which the uDma software interrupt vector is 62. there is no DMA interrupt on M3 part.

I think you probably mistake the interrupt vectors. You could see from the pic below, UART0 and UART1 interrupt number are 21 and 22.

Regards!

Lin

0 Oltan DOCI over 13 years ago in reply to LINHU YING

Prodigy 40 points

Sorry I thought that you were using the C28 core.

I'm using the C28 core for the UART on Concerto, that's why I have the interrupt numbers 96 & 97.

In the picture above the interruptions are for the M3 core so I can't use the numbers 21 & 22.

Thanks

0 LINHU YING over 13 years ago in reply to Oltan DOCI

Prodigy 135 points

Hi,Tom:

It seems that I found where is the problem. The problem is that you couldn't use #pragma to manage and allocate your menory space in your code with SYS/BIOS, it would generate unexpected problem if you use #pragma in your program. Maybe there exists some special mecchanism in SYS/BIOS which could do that job. Am I right?

To support my suspect, I let the compiler allocate .g_ulSrcBuf and .g_ulDstBuf automatically, and then I put .bss section into S07SHRAM manually. So the address of .g_ulSrcBuf and .g_ulDstBuf now are all located in the area(Shared Ram) where could be accessed by uDma without using #pragma. And finally it works perfect, I could see the data in .g_ulDstBuf and the interrupt trigger is kicked.

But I was still curious why I could not use #pragma in SYS/BIOS? Wait for your reply.

Regards!

Lin

0 Tom Kopriva over 13 years ago in reply to LINHU YING

TI__Mastermind 20480 points

Hi Linhu,

this is strange. Thanks for looking into this.

Could you post the versions of CCS and the Compiler tool that your project is using?

Can you also post the .map file of the build when you use the #pragma DATA_SECTION() where it doesn't work?

0 LINHU YING over 13 years ago in reply to Tom Kopriva

Prodigy 135 points

Hi, Tom

I'm current using CCS version:4.2.4.00034 with TMS470 Compiler.

And in attached with my .map file, 0285.udma_sysbios_m3.rar

Thanks!

0 Tom Kopriva over 13 years ago in reply to LINHU YING

TI__Mastermind 20480 points

Hi Linhu,

things look OK in your .map file. I was looking to see if your vector table is OK and if something looked to be out of place.

I can't say if the #pragma DATA_SECTION "breaks" things. You may want to export your complete project and post it. If I can't find any other problem with it, I'll have it forwarded to the compiler team to have them take a look at it.

An alternative approach though is to update your compiler to CCS v5.2.1 here. In this version you should also have the latest compiler tool TMS470 v4.9.5

0 LINHU YING over 13 years ago in reply to Tom Kopriva

Prodigy 135 points

Hi, Tom:

Sorry to answer you a little late cause last week I was in vacation. Thanks for your advices and I will try to update the CCS 5.1. But another engineer in my company said to me once that CCS5 is not so compatible with Concerto family devices as CCS4 and it's recommend to use CCS4 together with Concerto, is that ture?

Here is my whole sys/bios interrupt project file: 7571.udma_sysbios_interrupt.rar , thanks so much for your kindly help.

0 Tom Kopriva over 13 years ago in reply to LINHU YING

TI__Mastermind 20480 points

Hi Linhu,

I just ran your project and I got it to work with my changes, including with TMS470 v4.9.0

These are my changes:

unsigned int *Src_add = (unsigned int *)g_ulSrcBuf;
   for(Idx=0;Idx<1024;Idx++){
       *Src_add = Idx;
       Src_add ++;
   }

I added the control table to be also located in shared ram.

#pragma DATA_SECTION(ucControlTable, ".g_ulSrcBuf");

Then I saw the data in the destination buffer with an interrupt generated

I removed the IntEnable(INT_UDMA) function call. It's not a safe function to use with SYS/BIOS.

Your isr should ideally be something like:

Void myISR (UArg arg) {

}

0 LINHU YING over 13 years ago in reply to Tom Kopriva

Prodigy 135 points

Hi,Tom:

I followed your advice and modified my code, finally it works perfectly. I'm really appreciate your kindly help!

But I still couldn't understand why I have to add this code "#pragma DATA_SECTION(ucControlTable, ".g_ulSrcBuf")", to allocate the control table into the SharedRam? Does it force to do that?

Lin

0 Tom Kopriva over 13 years ago in reply to LINHU YING

TI__Mastermind 20480 points

Hi Linhu,

I'm not an expert with conceto's DMA but from my understanding when you start the DMA, it needs to read in the ucControlTable to determine what needs to be done. As with the g_ulSrcBuf and g_ulDstBuf buffers, if the table isn't accessible to the DMA, it can't determine what it needs to do.

I think with the tradeoffs with the "micro"DMA is that while it has less registers, it requires additional storage (e.g. ucControlTable) to function.

0 Jeanne Yi over 12 years ago in reply to Tom Kopriva

TI__Intellectual 860 points

Hi Tom,

I think for uDMA accessing, the data buffer must be assigned to the Address which can be accessed through uDMA.

To make the uDMA work successfully, we must confirm that the data bufffer such as g_ulSrcBuf to be in the C2 RAM to S7 RAM address. Do you agree with me?

I'm trying to do UART uDMA transportation with SYS/BIOS, I was blocked by the same problem yesterday. Thanks a lot for your comment which gave me the right direction.

Processors

Processors forum

Problem of SYS/BIOS integrated with uDma interrupt on Concerto