DMA filterblock to Control reg issue

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Dear Fourm,

   

Im attempting to transfer with the dma filter results from the holding register directly to a 8 bit control register.  I have been using the dma wizard to produce the needed code for configuring the dma.  When compiling Im getting a error Im not sure what to do with. 

   

Here is what the wizard is producing.

   

/* Variable declarations for FILT_DONE_DMA_LO */
/* Move these variable declarations to the top of the function */
uint8 FILT_DONE_DMA_LO_Chan;
uint8 FILT_DONE_DMA_LO_TD[1];

/* DMA Configuration for FILT_DONE_DMA_LO */
#define FILT_DONE_DMA_LO_BYTES_PER_BURST 1
#define FILT_DONE_DMA_LO_REQUEST_PER_BURST 1
#define FILT_DONE_DMA_LO_SRC_BASE (CYDEV_PERIPH_BASE)
#define FILT_DONE_DMA_LO_DST_BASE (CYDEV_PERIPH_BASE)
FILT_DONE_DMA_LO_Chan = FILT_DONE_DMA_LO_DmaInitialize(    FILT_DONE_DMA_LO_BYTES_PER_BURST,
                                                        FILT_DONE_DMA_LO_REQUEST_PER_BURST,
                                                        HI16(FILT_DONE_DMA_LO_SRC_BASE),
                                                        HI16(FILT_DONE_DMA_LO_DST_BASE));
FILT_DONE_DMA_LO_TD[0] = CyDmaTdAllocate();

CyDmaTdSetConfiguration(    FILT_DONE_DMA_LO_TD[0],
                            1,
                            DMA_INVALID_TD,
                            0);
                           
CyDmaTdSetAddress(    FILT_DONE_DMA_LO_TD[0],
                    LO16((uint32)Filter_1_HOLDA_PTR),
                    LO16((uint32)CTRL_REG_FILT_LO_Control_PTR));
                   
CyDmaChSetInitialTd(FILT_DONE_DMA_LO_Chan, FILT_DONE_DMA_LO_TD[0]);
CyDmaChEnable(FILT_DONE_DMA_LO_Chan, 1);

   

 

   

The error message is

   

prj.M0120:'CTRL_REG_FILT_LO_Sync_ctrl_reg__CONTROL_REG' undeclared (first use in this function)

   

 

   

The other dmas I have done I have not had a issue like this where the var is undeclared. 

   

#define CTRL_REG_SET_CURRENT_LO_Control_PTR    (  (reg8 *) CTRL_REG_SET_CURRENT_LO_Sync_ctrl_reg__CONTROL_REG )

   

 

   

Creator 2.2.0.293 and running cy8ckit-050 with a psoc5lp part.

   

Thanks for the help.

   

Matt

0 Likes
9 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

When you are in the stage of testing it might be that you do not have connected any hardware to the control-register yet. Thus the optimizer might have removed it which results in the above error.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Bob,

   

 

   

Thank you.  That was it.  I had the control regs connected to a digital comparator, but that was not connected to a io pin so yes it was being optimized out.  Again Thank you for your help!!!

   

 

   

Matt

0 Likes
Anonymous
Not applicable

I am currently having a similar issue while using the PSoC Sensei Parallel FIFO Input.  It posts:

   

M0120: 'FIFOIn_1_AsyncCtl_ControlReg__CONTROL_REG' undeclared.

   

I found the declaration in the .h file and .c file it refers to with the following outcome:

   

.h: #define FIFOIn_1_CONTROL_REG      (* (reg8 *) FIFOIn_1_AsyncCtl_ControlReg__CONTROL_REG)
.c: FIFOIn_1_CONTROL_REG |= FIFOIn_1_EN;    plus 2 other locations where the control reg is called.

   

I am using the PSOC 5LP dev kit 050A, when I ran this in the PSOC 5 dev kit it compiled and ran fine.  I am currently testing it, as Bobs reply had elluded to, but I am not sure what the fix was, or more precisely what the "flash of genious" was that solved rupertm's problem.  As best I can tell I have all connections made to the proper locations and nothing is left hanging.  Is this possibly an issue with cross compatability of the FIFO with PSOC 5LP, since it was developed for the PSOC 3?  I've attached my main file as well as a screen shot of my design thus far.  Thank you ahead of time for any help anybody can give me!

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Uploads are missing, use ie and not chrome

   

 

   

Bob

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Sorry, they should be attached now, thank you for your help.

0 Likes
Anonymous
Not applicable

I solved this issue, I just wanted to post my solution in case this occurs to anyone else and to verify that my solution is one free of bugs (which it probably isn't but it works). I had to modify the FIFOIn verilog file.  It seems that what it was doing was trying to verify that either PSOC 5ES1 or PSOC3 chips were being used, if not it was not syncing the register (or something of this nature).  On line 145 of "FIFOIn_v1_0.v" the AsyncCtl is checked with "if(PSOC3_ES2 || PSOC5_ES1)".  I simply changed this line to read "if(PSOC3_ES2 || PSOC5_ES1 || 1)" so that it is always true and always syncs the control register.  The code compiles now as works as expected, aside from some persistent clock warnings.

   

If anyone has any hints as to why I'm getting the following warnings I'd appreciate the feedback (probably belongs in a different forum post but I wanted to make this post as complete as possible):

   

Warning-1366: Setup time violation found in a path from clock (CyBUS_CLK) to clock (CyBUS_CLK).

   

Thank You!

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

To your question: short answer: you have a timing problem.

   

Long answer: It might be that your bus clock speed is too high for your setup, or that you exceed the timinf / frequency limits of a component. "setup time" refers to the time a component requires a certain signal to stay at its logical level so it can properly handle it. (E.g. when you have a DFF, it requires the level on the D input to be constant for a short period before (and maybe even after) the clock line goes high - if it doesn't you get undetermined results).

   

You can open the static timing report, and look where this error happens. If you know the components and the signals involved, you can try to clear the situation.

0 Likes
Anonymous
Not applicable

Thank you for the response, you are certainly correct that it is a timing issue, but how to solve it is a good question.  I would need to take the bus clock down to 43 MHz (as says the static timing analysis), but this seems unnecessary since everything else in the project runs fine at that speed, and I really need the extra clock cycles to handle CPU processes and stay ahead of my data gathering.  I'd like to put the clock through a  divider within the verilog, thus modifying the clock that the control register itself sees, but I'm not proficient enough with verilog to accomplish this.  Is there any tutorials or references anybody has that would explain this aspect of what I'm trying to accomplish?  I hope everything is clear, if not please let me know what I should clear up.  Thank you.

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

If you can identify the affected component, you can feed it with a lower clock, and use the highest possible one for the rest (esp. the core, if you need maximum CPU speed). You don't need to do this necessarily within verilog, you just need an external clock on the affected component.

0 Likes