Hi everbody!
I've encountered a strange problem on my 5509 EVM. The display uses GPIO 4
to indicate weather it's busy (low) or not (high). To read that bit is no
problem before I call the dsplib rfft algorithm, but after it doesn't work.
CCS says GPIO 4 high but still the program hangs on this instruction:
while( !(pGPIO-> iodata & GPIO_4));
Seems like the rfft is messing with something... ?
Does anyone recognize this problem?
Regards
Ola
GPIO 4 can't be read after rfft call
Started by ●December 6, 2005
Reply by ●December 6, 20052005-12-06
Ola-
> I've encountered a strange problem on my 5509 EVM. The display uses
> GPIO 4 to indicate weather it's busy (low) or not (high). To read
> that bit is no problem before I call the dsplib rfft algorithm, but
> after it doesn't work. CCS says GPIO 4 high but still the program
> hangs on this instruction:
>
> while( !(pGPIO-> iodata & GPIO_4));
>
> Seems like the rfft is messing with something... ?
>
> Does anyone recognize this problem?
Try calling rfft() with N = 4. If the problem goes away, then it may be
memory-related, maybe how mem for the input array for rfft was allocated.
-Jeff
> I've encountered a strange problem on my 5509 EVM. The display uses
> GPIO 4 to indicate weather it's busy (low) or not (high). To read
> that bit is no problem before I call the dsplib rfft algorithm, but
> after it doesn't work. CCS says GPIO 4 high but still the program
> hangs on this instruction:
>
> while( !(pGPIO-> iodata & GPIO_4));
>
> Seems like the rfft is messing with something... ?
>
> Does anyone recognize this problem?
Try calling rfft() with N = 4. If the problem goes away, then it may be
memory-related, maybe how mem for the input array for rfft was allocated.
-Jeff
Reply by ●December 6, 20052005-12-06
Ola-
> I've encountered a strange problem on my 5509 EVM. The display uses
> GPIO 4 to indicate weather it's busy (low) or not (high). To read
> that bit is no problem before I call the dsplib rfft algorithm, but
> after it doesn't work. CCS says GPIO 4 high but still the program
> hangs on this instruction:
>
> while( !(pGPIO-> iodata & GPIO_4));
>
> Seems like the rfft is messing with something... ?
>
> Does anyone recognize this problem?
Try calling rfft() with N = 4. If the problem goes away, then it may be
memory-related, maybe how mem for the input array for rfft was allocated.
-Jeff
> I've encountered a strange problem on my 5509 EVM. The display uses
> GPIO 4 to indicate weather it's busy (low) or not (high). To read
> that bit is no problem before I call the dsplib rfft algorithm, but
> after it doesn't work. CCS says GPIO 4 high but still the program
> hangs on this instruction:
>
> while( !(pGPIO-> iodata & GPIO_4));
>
> Seems like the rfft is messing with something... ?
>
> Does anyone recognize this problem?
Try calling rfft() with N = 4. If the problem goes away, then it may be
memory-related, maybe how mem for the input array for rfft was allocated.
-Jeff
Reply by ●December 7, 20052005-12-07
Ola-
> Thanks Jeff! But unfortunately it doesn't seem to make any difference.
Ok. Do u have source for rfft()? If so, then try modifying so the function returns
immediately, as first line of code. That should work... if it does, then u can go
step-by-step inside rfft() until u find the line that causes GPIO to stop.
-Jeff
>
> On 12/6/05, Jeff Brower <jbrower@jbro...> wrote:
> > Ola-
> >
> > > I've encountered a strange problem on my 5509 EVM. The display uses
> > > GPIO 4 to indicate weather it's busy (low) or not (high). To read
> > > that bit is no problem before I call the dsplib rfft algorithm, but
> > > after it doesn't work. CCS says GPIO 4 high but still the program
> > > hangs on this instruction:
> > >
> > > while( !(pGPIO-> iodata & GPIO_4));
> > >
> > > Seems like the rfft is messing with something... ?
> > >
> > > Does anyone recognize this problem?
> >
> > Try calling rfft() with N = 4. If the problem goes away, then it may be
> > memory-related, maybe how mem for the input array for rfft was allocated.
> >
> > -Jeff
> >
> Thanks Jeff! But unfortunately it doesn't seem to make any difference.
Ok. Do u have source for rfft()? If so, then try modifying so the function returns
immediately, as first line of code. That should work... if it does, then u can go
step-by-step inside rfft() until u find the line that causes GPIO to stop.
-Jeff
>
> On 12/6/05, Jeff Brower <jbrower@jbro...> wrote:
> > Ola-
> >
> > > I've encountered a strange problem on my 5509 EVM. The display uses
> > > GPIO 4 to indicate weather it's busy (low) or not (high). To read
> > > that bit is no problem before I call the dsplib rfft algorithm, but
> > > after it doesn't work. CCS says GPIO 4 high but still the program
> > > hangs on this instruction:
> > >
> > > while( !(pGPIO-> iodata & GPIO_4));
> > >
> > > Seems like the rfft is messing with something... ?
> > >
> > > Does anyone recognize this problem?
> >
> > Try calling rfft() with N = 4. If the problem goes away, then it may be
> > memory-related, maybe how mem for the input array for rfft was allocated.
> >
> > -Jeff
> >
Reply by ●December 9, 20052005-12-09
Ola-
> I checked how the mmr registers was affected by the rfft and saw that
> ARMS in statusreg 1 and SATD and FRCT in statusreg 2 was changed by
> the rfft. So I restored those bits after the call and everthing was
> back to normal.
>
> I also noticed that operations such as multiply and division didn't
> work as they should after the call so i suspected that some
> fundamental configuration of the DSP was changed in the rfft. And so
> it was... ;-)
Ok, good work. That sounds typical of dsplib.... You might want to put context
save/restore code inside rfft(); I've had to do that for TI functions before.
-Jeff
> On 12/7/05, Jeff Brower <jbrower@jbro...> wrote:
> > Ola-
> >
> > > Thanks Jeff! But unfortunately it doesn't seem to make any difference.
> >
> > Ok. Do u have source for rfft()? If so, then try modifying so the function returns
> > immediately, as first line of code. That should work... if it does, then u can go
> > step-by-step inside rfft() until u find the line that causes GPIO to stop.
> >
> > -Jeff
> >
> > >
> > > On 12/6/05, Jeff Brower <jbrower@jbro...> wrote:
> > > > Ola-
> > > >
> > > > > I've encountered a strange problem on my 5509 EVM. The display uses
> > > > > GPIO 4 to indicate weather it's busy (low) or not (high). To read
> > > > > that bit is no problem before I call the dsplib rfft algorithm, but
> > > > > after it doesn't work. CCS says GPIO 4 high but still the program
> > > > > hangs on this instruction:
> > > > >
> > > > > while( !(pGPIO-> iodata & GPIO_4));
> > > > >
> > > > > Seems like the rfft is messing with something... ?
> > > > >
> > > > > Does anyone recognize this problem?
> > > >
> > > > Try calling rfft() with N = 4. If the problem goes away, then it may be
> > > > memory-related, maybe how mem for the input array for rfft was allocated.
> > > >
> > > > -Jeff
> > > >
> >
> I checked how the mmr registers was affected by the rfft and saw that
> ARMS in statusreg 1 and SATD and FRCT in statusreg 2 was changed by
> the rfft. So I restored those bits after the call and everthing was
> back to normal.
>
> I also noticed that operations such as multiply and division didn't
> work as they should after the call so i suspected that some
> fundamental configuration of the DSP was changed in the rfft. And so
> it was... ;-)
Ok, good work. That sounds typical of dsplib.... You might want to put context
save/restore code inside rfft(); I've had to do that for TI functions before.
-Jeff
> On 12/7/05, Jeff Brower <jbrower@jbro...> wrote:
> > Ola-
> >
> > > Thanks Jeff! But unfortunately it doesn't seem to make any difference.
> >
> > Ok. Do u have source for rfft()? If so, then try modifying so the function returns
> > immediately, as first line of code. That should work... if it does, then u can go
> > step-by-step inside rfft() until u find the line that causes GPIO to stop.
> >
> > -Jeff
> >
> > >
> > > On 12/6/05, Jeff Brower <jbrower@jbro...> wrote:
> > > > Ola-
> > > >
> > > > > I've encountered a strange problem on my 5509 EVM. The display uses
> > > > > GPIO 4 to indicate weather it's busy (low) or not (high). To read
> > > > > that bit is no problem before I call the dsplib rfft algorithm, but
> > > > > after it doesn't work. CCS says GPIO 4 high but still the program
> > > > > hangs on this instruction:
> > > > >
> > > > > while( !(pGPIO-> iodata & GPIO_4));
> > > > >
> > > > > Seems like the rfft is messing with something... ?
> > > > >
> > > > > Does anyone recognize this problem?
> > > >
> > > > Try calling rfft() with N = 4. If the problem goes away, then it may be
> > > > memory-related, maybe how mem for the input array for rfft was allocated.
> > > >
> > > > -Jeff
> > > >
> >
