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.

ADC use with ePWM SOC on LAUNCHXL-F28377S - C2000 Multi-Day Workshop

Other Parts Discussed in Thread: TMS320F28377S, TMS320F28377D

Hello,

I am new in C2000 programming. I will start a question that is big, but threre's no way to axplain my problem, so I sorry for the English and the size of the post,

I'm studing LAUNCHXL-F28377S using the Workshop avaiable in .

In Lab 6, there's a exercise to learn how configurate the ADC trigered by ePWM2.

Although the workshop is to the TMS320F28377D, I made the necessary modifications to be compatible with my TMS320F28377S. This includes changing the headers and pins. As stated in the Student Guide:

The objective of this lab is to become familiar with the programming and operation of the on-chip analog-to-digital converter. The MCU will be setup to sample a single ADC input channel at a prescribed sampling rate and store the conversion result in a circular memory buffer.

In this lab, we will be using the ADC for data acquisition. Therefore, one of the ePWMs (ePWM2) will be configured to automatically trigger the SOCA signal at the desired sampling rate (ePWM period match CTR = PRD). The ADC end-of-conversion interrupt will be used to prompt the CPU to copy the results of the ADC conversion into a results buffer in memory. This buffer pointer will be managed in a circular fashion, such that new conversion results will continuously overwrite older conversion results in the buffer.

My main code is as follow, that is equal to the solution. There's nothing in the main loop and the processor just waits for the ePWM2 to triger the ADC converter:



The InitEPwm() is as follow, again equal to the solution. It enabled the generation of signal SOC0.


The InitAdca() is as follow. It setup the ADCINA0 to start after SOC0 and enable the interrupts.

The ADC end-of-conversion interrupt function, that will be used to prompt the CPU to copy the results of the ADC conversion into a results buffer in memory is as follow:

Now let's get to the problem:


When I monitor the AdcaResultRegs.ADCRESULT0 register, the values do not change, regardless of connecting ADCAIN0 input to GND or 3V3.
The ADCA interrupt call is working because when I put a breakpoint, the program stops, so I'm assuming SOC and ADC end-of-conversion (ADCA INT) is working for.

I have attached a zip file with the entire project.Lab6.zip

Again, sorry for the English and the size of the post, but this Labs workshop is driving me crazy.
I apreciate any help.



  • Hi Jose,

    A cursory look at your software shows that everything seems to be ok. I have 2 ideas:

    (1) Eallow is a bit in the CPU that prevents spurious writes to HW configuration registers. If the bit isn't set, some registers will ignore writes. Try single-stepping through your ADC and ePWM configurations. Whenever a configuration is written in SW, verify in the expressions window that the write did indeed take effect. Maybe because of this the ADC is clocked (so interrupts happen) but not powered up (so no real conversion results)?

    (2) If you are getting interrupts, it seems likely that the triggering is working correctly. This would point to a HW hook-up issue. Try changing the channel select for the ADC and keep looking at the device schematics carefully to ensure that you are forcing a voltage on the right channel. You can also try forcing something other than GND or 3.3V.
  • Jose,

    I reviewed your code and it looks like you mixed the workshop code with the header file example code.  This is not necessarily the same code - initialization and setting are in different places for each, so there could be a potential conflict.  The lab code from the workshop will work on the F28377S Launchpad, and you should not have any problems since this lab exercise only uses a single core.  For lab 6, the only minor modification that needs to be made is for the blinking LED showing that the ISR is running.  On the Launchpad, LED D9 is connected to GPIO12.  You need to modify the DefaultIsr.c ADCA1_ISR to use GPIO12 rather than GPIO34.  (GPIO34 is used on the Experimenter's Kit). Then modify GPIO.c (at the bottom) to use GPIO12 (in GPA) rather than GPIO34 (in GPB).  For labs 7 and beyond, you will need to modify the code to use ePWM3 rather than ePWM1 (since ePWM1 is not pinned out).  As a reference, I suggest watching my video, which for the most part runs lab 7 (and includes lab 6) on the Launchpad.  You can find the video at:

    Please try just using the lab code only and let me know what happens.  I hope this helps.

    - Ken

  • Dear Devin Cottier, thanks so much.

    Was exactly what you said. The EALLOW bit wasn't set and therefore the ADC wasn't powered up. Despite the EALLOW bit has been set in the beginning of the Adca.c file, the InitPieVectTable() function switches off it.
    After I put EALLOW command before the AdcaRegs.ADCCTL1.bit.ADCPWDNZ = 1 line, everything is working.

    Dear Ken Schachter, many thanks to you too.

    I had already seen this video. I even sent a comment asking where I could get the source code example. From what you wrote, this video uses the Lab7 from the same workshop, am I right?
    A second question about the headers: When the examples use only the CPU 1, I can use the same F28377D header files for F28377S?
    I'll try using the lab code only and I'll let you know.

    Best regards
  • Jose,

    I am glad that it is working.  This is what I was referring to by mixing the lab code with the header file example code could potentially result in a conflict.  You should be able to use the F28377D header files with the F28377S Launchpad when you are only using CPU1.  Please try this using the workshop code.  Again you will only need to make minor changes to the code to support the hardware differences between the Experimenter's Kit and Launchpad (i.e. LEDs, ePWM output, etc.).  And yes, the video is based on lab 7.  Please let me know what happens.

    - Ken

  • Ken Schachter,

    Everything worked normally.
    Even if I keep the TMS320F28377D device in the target configuration file and the Device Tap of the project properties. Everything worked normally.
    A warning message is given but it works normally (C28xx_CPU1: Flash Programmer: Warning: The configured device (TMS320F28377D), does not match the detected device (TMS320F28377S). Flash Programming operations could be affected. Please consider modifying your target configuration file.)

    Thanks.
  • Jose,

    Thanks for the update.  The lab 6 code is loaded to and runs from RAM.  Therefore, the linker command file used in this lab exercise does not have any sections allocated to flash.  Changing the device type in the target configuration file will eliminate the warning.  With the code modifications that I explained in the previous post, you should now be able to run all of the lab exercises in the workshop, with the exception of lab 11, which is the IPC dual-core lab exercise.  I hope this helps, and if all questions have been answered, please be sure to close this thread.

    - Ken