This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Can't run SPI and GPT at the same time

4442.bats_project_proj.rar

Hey all

I have little trouble getting the timer and spi working at the same time. You can find the according project attached to this post.

As long as I don't have init_spi() inside the init() function the timer is running fine at 600khz. As soon as I put in init_spi() the timer quits working (the pin doesn't toggle anymore).

 

I have no glue what the problem is ... so I hope someone can help me out soon....

 

Cheers

  • Okay, a little update: This morning I figured out that the ISR is running, but GPIO isnt. Also, SPI doesn't initialize properly. Sometimes it initializes, sometimes not. I put the init_spi() before and after init_gpt() and also I put init_gpio() after init_spi() and init_gpt() but no success.

    Someone?

     

    Edit: Another Update: I figured out that the the PPMODE has to set correctly. First, I changed the PPMODE in SPI_init() to 5, then to 1. Both should work, none does. Then I changed the place of SPI config so, that it is configured before GPIO. This doesn't help, too. Also, sometimes spi_open and spi_config doesn't work, I get the error message that open/config wasn't successful. Then I stop debugging and start again and the error is gone.

     

    I hope someone can help me soon ... Cheers

  • Does nobody have any idea?

  • Really, nobody? Hm :/ I think that GPIO is running, but the pin (14) is dead....

     

    Cheers

     

    Edit: I know now that the problem is located in this line

    CSL_FINS(sysRegs->EBSR, SYS_EBSR_PPMODE, CSL_SYS_EBSR_PPMODE_MODE6);

    But why? If I initialize GPIO before SPI and set pin14 to 1, the pin goes to 0 after this line.

  • Sorry for pushing again but my problem is really urgent ... I really really have no idea what the problem is but since yesterday I know where it is. Maybe someone knows how to set the EBSR register correctly - but I think it is set correctly.

     

    Cheers

  • Pushing again because I have no idea why the hack GPIO stops working at the point were EBSR is being set or why it isn't working when I set EBSR to Mode 1 or 6...

    Cheers

  • Hi Marc,

    Sorry for the delay. I would like to help you out with your GPIO problem.

    Are you using the C5515 eZdsp?

    What CSL version?

    The C5515 Datasheet reads "After changing any of the pin mux control registers, it will be necessary to reset the peripherals that are affected".
    So I'm not sure why the CSL SPI_init routine performs a peripheral reset BEFORE configuring EBSR, and not afterwards...

    How did you change the SPI_init routine to use PPMODE 1 or 6? Did you rebuild the CSL library?
    I would like you to halt the program after initialization and read the contents of the EBSR register from the View-->Memory window in CCS and verify that the PPMODE bits (14-12) of the EBSR are set correctly. EBSR is 0x1C00 in IO memory.

    In your program, you will need to configure the GPIOs after setting the EBSR.

    While you are checking registers in the memory window, also check...
    GPIO Direction Registers 1&2 (IODIR1 & IODIR2, 0x1C06 & 0x1C07 in IO memory) and
    GPIO Data Out Registers 1&2 (IODATAOUT1 & IODATAOUT2, 0x1C0A & 0x1C0B in IO memory)

    Make sure that they are configured correctly and that you can manually toggle the GPIO state by manipulating the appropriate bits in IODATAOUT1&2.

    Another test would be to toggle GPIO4 or GPIO5 instead of GPIO14 , as these are not muxed with any other pins and are not affected by the EBSR.

    Does the setPin function work as its supposed to when called from main.c (before the infinite while loop)? Check it by setting breakpoints after both setPin call.

    Let me know how it goes.

    Regards,
    Mark

  • I thank you very very very very much for your support.Three cheers for Mark, says Marc ;)

     

    So, back to work. I go sequentiell through your post:

    - Yes, I am using the eZdsp

    - I am using the newest CSL and CCS (last update one or two weeks ago)

    - Hm you're right. I missunderstood that the reset has to be AFTER setting EBSR. But in the csl source it's implemented the other way around

    - I did change it in the source and forgot about the library issue ... Yesterday evening I put some pointers on the according registers and commented the according lines in the according csl.c out and thought "it cannot be, there has to be a change". I put a printf into the source, it didn't appear. Then I thought "Aw, you dumbass... it's a lib ...".

    - setPin does work. As long as I don't use the spi module. Therefore, I think that GPIO is set correctly

    - GPIO Pin 4 is muxed! It is muxed by MMC0. In the csl_mmc.c you can see that both modules are set (SPMODE is set for both modules, so muxing is a issue for this pin too)

    - Okay, Hex number party:

    Setup 1: init_spi, init_gpio, set_pin_to_one(4), set_pin_to_one(14), init_gpt, init_mmc_sd, init_fs, init_interrupts

    Breakpoints after init_spi (1), init_gpio (2), init (3)

    1 2 3
    0x1C00 0x5000 0x5000 0x5000
    0x1C06 0x5010 0x5010 0x5010
    0x1C07 0x0000 0x0000 0x0000
    0x1C0A 0x4000 0x4010 0x4010
    0x1C0B 0x0000 0x0000 0x0000

    GPIO is always 0 (meassured with a oscilloscope)

    Setup 2: init_gpio, set_pin_to_one(4), set_pin_to_one(14), init_spi, init_gpt, init_mmc_sd, init_fs, init_interrupts

    Breakpoints after init_gpio (1), init_spi (2), init (3)


    1
    2
    3
    0x1C00
    0x5000
    0x5000
    0x5000
    0x1C06
    0x5010
    0x5010
    0x5010
    0x1C07
    0x0000
    0x0000
    0x0000
    0x1C0A
    0x4010
    0x4010
    0x4010
    0x1C0B
    0x0000
    0x0000
    0x0000

    GPIO Pin 4 and 14 are both 1 before init_spi, Pin14 is 0 after init_spi, Pin4 afte init_mmcsd

    I didn't try to change the data out because it seems that there's a one set, but the pin is dead.

     

    I think, as you mentioned above, that the problem is that the reset is before seting EBSR and that EBSR is set two times (in spi and mmcsd). I would say that I write the EBSR routine for my self with pointer. But for that I would have to disable the according lines in init spi and mmcsd and I dunno how to change the lib ;)

     

    Thanks for your help again. I was starting to think on a plan B (which would be to try to use the internal SAR instead of my external but the internal could be too slow ...).

    Cheers!

     

    Edit: Maybe the best thing to try as a next step is to take all the header and source files, put them into my project, include the according .h as a local file ("*.h") and let the compiler do its thing with the files. Doing this, the source files could be manipulated which means the suspicious lines of code could be disabled by comments and a own routine to set the EBSR register for PPMODE and SPMODE can be made. Also, it can be made in the right order.

    And I had a idea today which could be seen as a suggestion for the next CSL version: The current CSL version or rather whose modules are very static. If I am using more than one module which sets PPMODE or SPMODE at once the register is set wrong because it is set several times. Also if I am using SPI and the other pins as GPIO I am in trouble too because I can't change it easily. And last not but least: Both MMC/SD modules are set by SPMODE0, in the case of the eZdsp one can be used.

    This could be made more flexibel. With a routine alá pin_setup where I can choose which pin setup I would like to use. This routine would provide setting the according modes in the register and also performing the reset of the according hardware modules. This would be way much better I think because it makes the library more flexibel.

     

    Oh my gosh, so much text ^^

     

    Edit: Even more text: I tried to re-build the lib project but I got 84 Assembly Errors...