Sign in
Search c55x
Subscribe to c55x
c55x by Keywords
AIC23 | C5509 | CCS | CSL | EMIF | EVM | GEL | GPIO | HPI | Interfacing | JTAG | McBSP | OMAP | Omap15 | OMAP59 | RTDX | SDRAM | TMS320VC5509 | USB | XDS5
Discussion Groups
Discussion Groups | TMS320C55x | LOG_Printf & interrupt [C5509]
Technical discussions about the TI C55x DSPs (including the c5501, c5502, c5503, c5507, c5509, c5510 and OMAP5910).
McBSP2 on 5502, does it work? - andrewpasquale - Nov 14 3:24:00 2003
|
Hello All, Has anbody been able to use McBSP2 on the 5502 at all? We cannot mux the SP0, SP1, SP2, SP3 pins to the McBSP2. We are using the TI TMX320VC5502PGF DSP and are encountering a debilitating problem with the device not mentioned in the silicon errata. Specifically, we have tied GPIO7 to 3.3V so that at reset the SP0, SP1, SP2, SP3 pins are tied to the McBSP serial signals (see sprs166e.pdf p48), simple enough. However upon reading the XBSR register (with CHIP_RGET(XBSR)), bit 2 of the XBSR (representing the state of GPIO7) is 0 !!!!! And hence we can not use McBSP2 (no clock or transmission signal come out). Note, - We have tested the actual pin, and it is at 3.3V. - We have also tied GPIO6 to 3.3V so that the EMIF is selected. Testing the XBSR register bit 0 DOES give the correct value of 1, so it just seems to be a problem with the GPIO7. - We have tried writing to the XBSR register to set BIT 2 to 1 (even though it is not recommended, see note at bottom of page), and we can see that this does make bit 2 of XBSR = 1, however the McBSP2 is still not enabled (no clock or signals out). - Why is writing to the XBSR register not recommended? (the 3.3V pull up on our board goes through a 10KOhm res) So has anybody actually been able to use McBSP2 on the 5502 at all? Is it just our chips, or are we forgetting something? Please help us. |
|
|
(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )
Re: McBSP2 on 5502, does it work? - M B - Nov 14 15:48:00 2003
|
Hi Andrew Couple of things you can check ... 1) Read up the GPIO7 value,so that you know what the DSP thinks it has for GPIO7, this you can do by setting up the GPI07 as input and read the GPIO data register. 2) If the value of GPI07 is what you expected, the other thing that you might want to check is the boot mode. If your GPIO[0:2] is set for UART bootmode (111), then the UART bootmode code is going to programme the XBSR register to enable the UART, and would override your GPIO7 settings. A simple test to see whether the McBSP2 has been enabled is just to verify the McBSP2 I/O registers (from 0x3000)can be read from the CCS Memory window. If they are visible then McBSP2 should be enabled. Hope this helps. Regards MB --- andrewpasquale <> wrote: > Hello All, > Has anbody been able to use McBSP2 on the 5502 at > all? We cannot mux > the SP0, SP1, SP2, SP3 pins to the McBSP2. > > We are using the TI TMX320VC5502PGF DSP and are > encountering a > debilitating problem with the device not mentioned > in the silicon > errata. > Specifically, we have tied GPIO7 to 3.3V so that at > reset the SP0, > SP1, SP2, SP3 pins are tied to the McBSP serial > signals (see > sprs166e.pdf p48), simple enough. However upon > reading the XBSR > register (with CHIP_RGET(XBSR)), bit 2 of the XBSR > (representing the > state of GPIO7) is 0 !!!!! And hence we can not use > McBSP2 (no clock > or transmission signal come out). Note, > - We have tested the actual pin, and it is at 3.3V. > - We have also tied GPIO6 to 3.3V so that the EMIF > is selected. > Testing the XBSR register bit 0 DOES give the > correct value of 1, so > it just seems to be a problem with the GPIO7. > - We have tried writing to the XBSR register to set > BIT 2 to 1 (even > though it is not recommended, see note at bottom of > page), and we can > see that this does make bit 2 of XBSR = 1, however > the McBSP2 is > still not enabled (no clock or signals out). > - Why is writing to the XBSR register not > recommended? (the 3.3V > pull up on our board goes through a 10KOhm res) > > So has anybody actually been able to use McBSP2 on > the 5502 at all? > Is it just our chips, or are we forgetting > something? > Please help us. > > ------------------------ Yahoo! Groups Sponsor > > _____________________________________ ________________________________________________________________________ Yahoo! India Mobile: Download the latest polyphonic ringtones. Go to http://in.mobile.yahoo.com |
|
|
(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )
LOG_Printf & interrupt [C5509] - Pierre Albart - Nov 17 15:10:00 2003
|
Hello, I noticed the CSL function LOG_printf(LOG_Handle, String , ...) globally enable the interrupts (by setting the INTM bit of ST1_55 to 0) ? Why this ? Thanks for reading me. |
|
|
(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )
RE: LOG_Printf & interrupt [C5509] - Pierre Albart - Nov 18 9:10:00 2003
|
Dear Mr Pignon, I guess the normal procedure is to save the INTM status at the beginning of the LOG_printf handler, than disable temporally the interrupts (INTM set to 1), and finally restore the INTM bit to its previous state before returning. BUT in my case, I see that the INTM bit is clear (interrupts reenabled) after the LOG_printf call in each case, whether the interrupt were enabled or not before the call. At 09:53 18/11/2003, Paul Pignon wrote: Pierre, Address Office Tel Fax |
(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )