Re: PWM driver tested in RTEMS with RGB
On Thu, May 12, 2016 at 6:55 PM, Martin Galvan wrote: > Hi Punit! Sorry I didn't answer, I was off sick for a couple days. Marcos > and I are a bit crowded so we can't review every bit of your patch right now > (plus we don't have our BBB anymore). Could you make the RGB test work using > SW code only? Hi all, I tested test suite which only use TI SW API. Like as follow : https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/fail.c Whatever frequency I change LED glows continuously only. In between CMPA or CMPB whichever is higher , that respective EPWMA or EPWMB is more brighter.That is the only difference I found out. Second test case which is with custom function not with TI SW only : https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/success.c Here whatever frequency I pass as argument , LED blinks at same rate. There is no difference. If I set different duty cycle for EPWMA and EPWMB, LED glowing time is more for which duty cycle is higher. But it seems in this case PWM wave generates , not sure at which frequency. To calculate frequency(UP or DOWN count only) equation is TPWM = (TBPRD + 1) x TBCLK FPWM = 1/TPWM In program we need to assign value to TBPRD register. Another important equation to remember is TBCLK = SYSCLKOUT/(HSPCLKDIV *CLKDIV) How to calculate duty cycle ? Simply value need to pass to CMPA or CMPB register. I am trying to generate testcase which can generate different frequencies with different duty cycle on LED with TI SW. I tried to debug with printf but dont know how to use that results. Can you suggest me any test cases so that I can able to find what is the problem with code ? Any conclusion why in one case LED just blinks and in another it just glows continuous. ? Any help will be appreciated. :-) Thank you, Punit Vara ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PWM driver tested in RTEMS with RGB
Please consider following code as reference original code. https://github.com/punitvara/TI-Starterware I have forked from sourceforge repo that I have already discussed. https://sourceforge.net/p/starterwarefree/code/ci/master/tree/ On Tue, May 10, 2016 at 7:44 PM, punit vara wrote: > On Fri, May 6, 2016 at 5:22 PM, Chris Johns wrote: >> On 6/05/2016 9:47 PM, punit vara wrote: >>> >>> Official TI wiki page. http://processors.wiki.ti.com/index.php/StarterWare >>> leads me to same repo. >>> >>> If you are saying here we need to be careful than I would like to have >>> a suggestion from my mentors that from where should I copy the code ? >>> I think few days back Martin and Marcos both discussed licence issue >>> with Gedare. I hope they can help me regarding this. >> >> This is what I was after. The link is on a TI domain and as you indicate >> it does point to the SF site. >> >> Thanks for providing this. The code looks fine to me. >> >> Chris > Hi all! > > I have successfully added original Ti Starter Ware code to RTEMS. > RTEMS build is also successful with this code. > Well patch is quite big but I will reduce size as community suggests. > > Licence is added to .c file > Coding style preserved to original TI SW. > Full header file added from TI SW as it will be helpful for other BSP > development for BBB. > > Please review code and let me know the issue. > > https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/patch/0001-Added-original-Ti-StarterWare-with-successful-build.patch > > This is my first patch after getting selected in GSOC'16. Any > suggestions are most welcome. > Thank you, > Punit Vara ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PWM driver tested in RTEMS with RGB
On Fri, May 6, 2016 at 5:22 PM, Chris Johns wrote: > On 6/05/2016 9:47 PM, punit vara wrote: >> >> Official TI wiki page. http://processors.wiki.ti.com/index.php/StarterWare >> leads me to same repo. >> >> If you are saying here we need to be careful than I would like to have >> a suggestion from my mentors that from where should I copy the code ? >> I think few days back Martin and Marcos both discussed licence issue >> with Gedare. I hope they can help me regarding this. > > This is what I was after. The link is on a TI domain and as you indicate > it does point to the SF site. > > Thanks for providing this. The code looks fine to me. > > Chris Hi all! I have successfully added original Ti Starter Ware code to RTEMS. RTEMS build is also successful with this code. Well patch is quite big needed moderator approval but I will reduce size as community suggests. Licence is added to .c file Coding style preserved to original TI SW. Full header file added from TI SW as it will be helpful for other BSP development for BBB. Please review code and let me know the issue. https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/patch/0001-Added-original-Ti-StarterWare-with-successful-build.patch Please consider following code as reference original code. https://github.com/punitvara/TI-Starterware I have forked from sourceforge repo that I have already discussed. https://sourceforge.net/p/starterwarefree/code/ci/master/tree/ This is my first patch after getting selected in GSOC'16. Any suggestions are most welcome. Thank you, Punit Vara ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PWM driver tested in RTEMS with RGB
Hi Punit! Sorry I didn't answer, I was off sick for a couple days. Marcos and I are a bit crowded so we can't review every bit of your patch right now (plus we don't have our BBB anymore). Could you make the RGB test work using SW code only? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PWM driver tested in RTEMS with RGB
On 6/05/2016 9:47 PM, punit vara wrote: > > Official TI wiki page. http://processors.wiki.ti.com/index.php/StarterWare > leads me to same repo. > > If you are saying here we need to be careful than I would like to have > a suggestion from my mentors that from where should I copy the code ? > I think few days back Martin and Marcos both discussed licence issue > with Gedare. I hope they can help me regarding this. This is what I was after. The link is on a TI domain and as you indicate it does point to the SF site. Thanks for providing this. The code looks fine to me. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PWM driver tested in RTEMS with RGB
On Fri, May 6, 2016 at 7:23 AM, Chris Johns wrote: > On 05/05/2016 22:25, punit vara wrote: >> >> >> I have referred code from sourceforge. >> >> https://sourceforge.net/p/starterwarefree/code/ci/master/tree/ >> > > I am sorry but I am not comfortable with this repo at the moment and I would > like to have origin of the code verified before any code from it enters > RTEMS. The repo does not have a LICENSE file at the top and the > AM335X_SoftwareManifest.pdf has "Ti Confidential" on every page yet it is > public. If this code have been placed in a public repo after someone > acknowledged an EULA then we need to be careful. > > Chris Hi Official TI wiki page. http://processors.wiki.ti.com/index.php/StarterWare leads me to same repo. If you are saying here we need to be careful than I would like to have a suggestion from my mentors that from where should I copy the code ? I think few days back Martin and Marcos both discussed licence issue with Gedare. I hope they can help me regarding this. Regards, Punit Vara ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PWM driver tested in RTEMS with RGB
On 05/05/2016 22:25, punit vara wrote: I have referred code from sourceforge. https://sourceforge.net/p/starterwarefree/code/ci/master/tree/ I am sorry but I am not comfortable with this repo at the moment and I would like to have origin of the code verified before any code from it enters RTEMS. The repo does not have a LICENSE file at the top and the AM335X_SoftwareManifest.pdf has "Ti Confidential" on every page yet it is public. If this code have been placed in a public repo after someone acknowledged an EULA then we need to be careful. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PWM driver tested in RTEMS with RGB
On Wed, May 4, 2016 at 8:31 AM, Chris Johns wrote: > On 04/05/2016 11:53, Gedare Bloom wrote: >>> >>> >>> I added Ti licence at last patch. Do I need to add any other licence ? >> >> Whenever you copy/paste code, you need to know/observe what the >> license is and keep track of that. So, the question of whether you >> need to add another license depends on whether you copied code from >> somewhere that has a different license. I copied the code from 2 files. Both files have same licence . So the licence I added is enough according to me. > > Where did the TI code from, for example a public tarball, a public TI git > repo, or a TI SDK? I have referred code from sourceforge. https://sourceforge.net/p/starterwarefree/code/ci/master/tree/ @Martin you can clone this code and keep it handy while reviewing my code. SW code is cloned from following link. git clone git://git.code.sf.net/p/starterwarefree/code starterwarefree-code This repo represents 2.0.x variant of SW by TI. @Martin For further communication should I communicate here or should I create new thread in user@rtems. I am asking because Gedare told to introduce project on user@rtems mail list but you mostly prefer devel@rtems. If I add code from anywhere else I will inform community. Thanks for the support. Regards, Punit Vara ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PWM driver tested in RTEMS with RGB
On 04/05/2016 11:53, Gedare Bloom wrote: I added Ti licence at last patch. Do I need to add any other licence ? Whenever you copy/paste code, you need to know/observe what the license is and keep track of that. So, the question of whether you need to add another license depends on whether you copied code from somewhere that has a different license. Where did the TI code from, for example a public tarball, a public TI git repo, or a TI SDK? If the code has come from a TI downloaded developers SDK with a front end EULA then we need to understand the exact licensing terms the code has been provided under. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PWM driver tested in RTEMS with RGB
On Sat, Apr 30, 2016 at 10:37 PM, punit vara wrote: > Sorry for late reply. Thank you for your detailed review. I am still > busy this week with my academic work.I would like to have suggestions > on my proposal. > > Should I change anything in my proposal like title or any other detail > ? Any suggestions ? > > Is there any vim setup instruction for RTEMS coding style(i.e Linux > community has). If not ? I would love to develop vim plugin if it is > possible to develop in less time. It will be useful for every RTEMS > developer. > > On Tue, Apr 26, 2016 at 8:21 PM, Martin Galvan > wrote: >> Hi Punit! Sorry for the delay; I finally got to review your code. >> First and foremost, it'd be great if you could tell us which >> StarterWare version/git commit are you using, so that we can keep it >> handy when reviewing your code. Sorry if you already mentioned it, my >> memory is a bit sketchy these days :) >> >> As a general comment I'd say you should keep a consistent coding style >> throughout the code you write yourself. While the core RTEMS style >> (spaces after parentheses, etc) isn't required in BSP code, at least >> indentations should be correct. Indentations in RTEMS are usually two >> spaces. >> >> More on coding style later. >> >> On Fri, Apr 15, 2016 at 4:48 PM, punit vara wrote: >>> This is my first patch I already sent you when I successfully merged TI SW >>> code. >>> >>> https://github.com/punitvara/rtems_gsoc16/tree/master/pwm/patch >> >> I take it you're referring to 0001-add-new-pwm-driver.patch. A few comments: >> >> 1) Whenever possible, try to keep the original coding style for >> imported code. This makes it easier to track changes and such. Same >> goes for e.g. the order in which functions are declared (e.g. >> EHRPWMConfigureAQActionOnA and B). >> >> 2) I think you should add the TI license to bbb-pwm.c as well. It >> would also be really nice if you added a comment atop the imported >> files saying which SW version/git commit they come from. > > https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/patch/0001-PWM-successful-code-added.patch > > I added Ti licence at last patch. Do I need to add any other licence ? Whenever you copy/paste code, you need to know/observe what the license is and keep track of that. So, the question of whether you need to add another license depends on whether you copied code from somewhere that has a different license. > I will update my local repo with your other suggestion. I considered > all your suggestions. I will soon generate some patches and show you. > Then you can guide me further. > > Once again thank you for mentoring every one. > > Regards, > Punit Vara ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PWM driver tested in RTEMS with RGB
Sorry for late reply. Thank you for your detailed review. I am still busy this week with my academic work.I would like to have suggestions on my proposal. Should I change anything in my proposal like title or any other detail ? Any suggestions ? Is there any vim setup instruction for RTEMS coding style(i.e Linux community has). If not ? I would love to develop vim plugin if it is possible to develop in less time. It will be useful for every RTEMS developer. On Tue, Apr 26, 2016 at 8:21 PM, Martin Galvan wrote: > Hi Punit! Sorry for the delay; I finally got to review your code. > First and foremost, it'd be great if you could tell us which > StarterWare version/git commit are you using, so that we can keep it > handy when reviewing your code. Sorry if you already mentioned it, my > memory is a bit sketchy these days :) > > As a general comment I'd say you should keep a consistent coding style > throughout the code you write yourself. While the core RTEMS style > (spaces after parentheses, etc) isn't required in BSP code, at least > indentations should be correct. Indentations in RTEMS are usually two > spaces. > > More on coding style later. > > On Fri, Apr 15, 2016 at 4:48 PM, punit vara wrote: >> This is my first patch I already sent you when I successfully merged TI SW >> code. >> >> https://github.com/punitvara/rtems_gsoc16/tree/master/pwm/patch > > I take it you're referring to 0001-add-new-pwm-driver.patch. A few comments: > > 1) Whenever possible, try to keep the original coding style for > imported code. This makes it easier to track changes and such. Same > goes for e.g. the order in which functions are declared (e.g. > EHRPWMConfigureAQActionOnA and B). > > 2) I think you should add the TI license to bbb-pwm.c as well. It > would also be really nice if you added a comment atop the imported > files saying which SW version/git commit they come from. https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/patch/0001-PWM-successful-code-added.patch I added Ti licence at last patch. Do I need to add any other licence ? I will update my local repo with your other suggestion. I considered all your suggestions. I will soon generate some patches and show you. Then you can guide me further. Once again thank you for mentoring every one. Regards, Punit Vara ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PWM driver tested in RTEMS with RGB
Hi Punit! Sorry for the delay; I finally got to review your code. First and foremost, it'd be great if you could tell us which StarterWare version/git commit are you using, so that we can keep it handy when reviewing your code. Sorry if you already mentioned it, my memory is a bit sketchy these days :) As a general comment I'd say you should keep a consistent coding style throughout the code you write yourself. While the core RTEMS style (spaces after parentheses, etc) isn't required in BSP code, at least indentations should be correct. Indentations in RTEMS are usually two spaces. More on coding style later. On Fri, Apr 15, 2016 at 4:48 PM, punit vara wrote: > This is my first patch I already sent you when I successfully merged TI SW > code. > > https://github.com/punitvara/rtems_gsoc16/tree/master/pwm/patch I take it you're referring to 0001-add-new-pwm-driver.patch. A few comments: 1) Whenever possible, try to keep the original coding style for imported code. This makes it easier to track changes and such. Same goes for e.g. the order in which functions are declared (e.g. EHRPWMConfigureAQActionOnA and B). 2) I think you should add the TI license to bbb-pwm.c as well. It would also be really nice if you added a comment atop the imported files saying which SW version/git commit they come from. 3) Are those REG* macros in the original SW code? I recall having seen them defined in RTEMS, while SW used HWREG*. If they're from RTEMS, please generate a patch that adds the vanilla SW code, then a second one with your changes to adapt it to RTEMS like Gedare suggested. I saw you already did that with SOC_CONTROL_REGS -> AM335X_PADCONF_BASE. 4) I saw that on bbb-pwm.c you placed functions from different SW files (e.g. PWMSSModuleClkConfig comes from platform/evmAM335x/pwmss.c while EHRPWMTimebaseClkConfig comes from drivers/ehrpwm.c). While I agree that it's not necessary to maintain the exact same file structure from SW, it'd be nice if you grouped each set of functions from a SW file together and added a comment atop saying something like /* These functions come from drivers/ehrpwm.c in TI StarterWare */. However that's just my opinion; perhaps there's a better way to do this (Gedare?). 5) I'm seeing your patch includes changes to a couple of M4 files. This probably comes from a bootstrap, and should be kept off your final patch. > 2. Second patch which shows I added useful registers from TI SW header files > > https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/patch/0002-add-register-for-pwm-driver.patch > > After above two patches I created testsuite > > https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/fail.c >From what I'm seeing, your example comes from examples/evmAM335x/ehrpwm_haptics/ehrpwm_haptics.c, which drives a Pico-Haptics 304-100 motor that's connected to the B-Channel of the PWMSS2 of the AM335x EVM. I've taken a look at your version vs the SW example, and while I can't immediately point out what's wrong I suspect there may be some register magic your code is missing, or perhaps some of the values aren't being set correctly. In any case, double-check the SW example with the AM335x Technical Reference Manual; don't rule out bugs in SW itself. > In this testsuite, LED is constantly glowing as I told. No matter what > counter I set or frequency set I am not able to get expected output. > > 3. Then I added three new function that can be seen in below patch.TI > Copy right is also added as Gedare Bloom suggested me. > > https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/patch/0001-PWM-successful-code-added.patch Don't forget to mark the code changes with #if defined(__rtems__) like Gedare suggested. > You should look these definition in patch. I wrote this after first > failed testsuite. > > - PWMSS_Setting > - ehrPWM_Enable > - ehrPWM_Disable > - EPWMPinMuxSetup This last function I also used in first test case. If you are going to keep those functions I think you should improve the coding style a bit (e.g. name them using CamelCase as the rest of SW code, avoid magic numbers, etc). I think for now we should focus on making your PWM example work using the SW APIs. If you realize it definitely won't work because the API has a bug, you should patch the API. All in all, good work! ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PWM driver tested in RTEMS with RGB
On Fri, Apr 15, 2016 at 12:35 AM, Martin Galvan wrote: > > On Thu, Apr 14, 2016 at 1:34 PM, punit vara wrote: > > Hi all ! > > > > I had successfully merged the TI Starter Ware Code with RTEMS. > > That's great. Could you show us the resulting directory structure > (perhaps with a diffstat), as well as the changes to Makefile.am? > This is my first patch I already sent you when I successfully merged TI SW code. https://github.com/punitvara/rtems_gsoc16/tree/master/pwm/patch 2. Second patch which shows I added useful registers from TI SW header files https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/patch/0002-add-register-for-pwm-driver.patch After above two patches I created testsuite https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/fail.c In this testsuite, LED is constantly glowing as I told. No matter what counter I set or frequency set I am not able to get expected output. 3. Then I added three new function that can be seen in below patch.TI Copy right is also added as Gedare Bloom suggested me. https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/patch/0001-PWM-successful-code-added.patch You should look these definition in patch. I wrote this after first failed testsuite. - PWMSS_Setting - ehrPWM_Enable - ehrPWM_Disable - EPWMPinMuxSetup This last function I also used in first test case. > > Then I tried > > to test it with sample application with RGB. As a result I was able to glow > > the LED with that code but unfortunately, LED was only glowing constantly. > > It did not blink (at all !!!) according to duty cycle and frequency. > > Odd. Could you post your test program (or preferably a link to it)? > Perhaps we can look into some of the APIs and see what's wrong. > > > Yesterday I written my own functions similarly as Worth Burruss suggested > > me. But they are not exactly same as he told. Those functions are > > > > 1. To initialize PWM > > 2. To Enable PWM > > 3. To Disable PWM > > 4. Pinmux for PWM module > > > > I have used some Ti Starter Ware clock config functions along with my own > > written functions and successfully able to test PWM driver on RGB LED. Video > > is uploaded on youtube and please find the link as below. > > So if I understand correctly, you were able to make this work by > writing your own code to access the PWM instead of the StarterWare > API? I'd like to see that code as well so we can compare it to > StarterWare's. Three functions I wrote are not enough to generate PWM. I have used following definitions from TI SW code to generate PWM waveform. - PWMSSModuleClkConfig() - EHRPWMClockEnable() - PWMSSTBClkEnable() > > > https://www.youtube.com/watch?v=KsdtgVj-ZxU > > > > Please let me know if is there any problems with video. > > Looks good! > > > Martin, you told there are problem with some functions it would be better if > > you can share so that I can troubleshoot which TI Starter Ware code should I > > edit. Any comments and suggestions from community members are most welcome. > > I will soon share the code after suggestions or comments. > > I just ran a diff between our sources and the SW version we downloaded > back then, found here: > > http://software-dl-1.ti.com/dsps/forms/self_cert_export.html?prod_no=AM335X_StarterWare_02_00_01_01_Setup.bin&ref_url=http://software-dl.ti.com/dsps/dsps_public_sw/am_bu/starterware/latest/ > > (You need to register a free account to download it). > > From what I saw, most of the changes we did were removing unused code > and fixing mostly cosmetic issues. I'm attaching the diff file so you > can take a look at it. I think one of the most important differences > are the changes in utils/delay.c; Sysdelay was replaced by usleep. > Don't ask me why though, that was a long time ago and it wasn't me who > did it :) > > I also saw that SW has a git repository, which seemingly has quite a > few differences from the version we were using. Those seem to be > mostly related to FatFS though. > > If I were you, I'd give the old SW code + our patch a shot, then if it > works I'd try to replicate some of the changes on the SW git. > > Unfortunately, Marcos and I won't be able to test your progress > because we don't have our BBBs available anymore. We can still review > your code though, and I think Ben has a BBB if you want additional > testing. > > On a related note, it would be better if you posted your progress on a > single thread so it's easier to keep track of. No need to open a new > one for each milestone. >From now on wards I will reply on this thread so this would be easier to track for you. Right now I added PWM APIs in ../libbsp/shared/include/gpio.h. Later on can be changed as community suggest. Please do let me know If I am not proper with copy right or any similar kind of issues. Function I wrote is inspired from below reference. https://github.com/VegetableAvenger/BBBIOlib I hope there is no issue with licence. As always I am always open to consider all comments and suggestions.
Re: PWM driver tested in RTEMS with RGB
On Thu, Apr 14, 2016 at 1:34 PM, punit vara wrote: > Hi all ! > > I had successfully merged the TI Starter Ware Code with RTEMS. That's great. Could you show us the resulting directory structure (perhaps with a diffstat), as well as the changes to Makefile.am? > Then I tried > to test it with sample application with RGB. As a result I was able to glow > the LED with that code but unfortunately, LED was only glowing constantly. > It did not blink (at all !!!) according to duty cycle and frequency. Odd. Could you post your test program (or preferably a link to it)? Perhaps we can look into some of the APIs and see what's wrong. > Yesterday I written my own functions similarly as Worth Burruss suggested > me. But they are not exactly same as he told. Those functions are > > 1. To initialize PWM > 2. To Enable PWM > 3. To Disable PWM > 4. Pinmux for PWM module > > I have used some Ti Starter Ware clock config functions along with my own > written functions and successfully able to test PWM driver on RGB LED. Video > is uploaded on youtube and please find the link as below. So if I understand correctly, you were able to make this work by writing your own code to access the PWM instead of the StarterWare API? I'd like to see that code as well so we can compare it to StarterWare's. > https://www.youtube.com/watch?v=KsdtgVj-ZxU > > Please let me know if is there any problems with video. Looks good! > Martin, you told there are problem with some functions it would be better if > you can share so that I can troubleshoot which TI Starter Ware code should I > edit. Any comments and suggestions from community members are most welcome. > I will soon share the code after suggestions or comments. I just ran a diff between our sources and the SW version we downloaded back then, found here: http://software-dl-1.ti.com/dsps/forms/self_cert_export.html?prod_no=AM335X_StarterWare_02_00_01_01_Setup.bin&ref_url=http://software-dl.ti.com/dsps/dsps_public_sw/am_bu/starterware/latest/ (You need to register a free account to download it). >From what I saw, most of the changes we did were removing unused code and fixing mostly cosmetic issues. I'm attaching the diff file so you can take a look at it. I think one of the most important differences are the changes in utils/delay.c; Sysdelay was replaced by usleep. Don't ask me why though, that was a long time ago and it wasn't me who did it :) I also saw that SW has a git repository, which seemingly has quite a few differences from the version we were using. Those seem to be mostly related to FatFS though. If I were you, I'd give the old SW code + our patch a shot, then if it works I'd try to replicate some of the changes on the SW git. Unfortunately, Marcos and I won't be able to test your progress because we don't have our BBBs available anymore. We can still review your code though, and I think Ben has a BBB if you want additional testing. On a related note, it would be better if you posted your progress on a single thread so it's easier to keep track of. No need to open a new one for each milestone. Only in starterware-ti: AM335X_SoftwareManifest.pdf Only in starterware-ti: AM335X_StarterWare_02_00_01_01_Setup.bin Only in starterware-ti: binary Only in starterware-ti: bootloader Only in starterware-ti: build Only in starterware-ti: docs diff -ruw starterware-ti/drivers/cppi41dma.c starterware-taller/drivers/cppi41dma.c --- starterware-ti/drivers/cppi41dma.c 2013-07-11 18:22:51.0 -0300 +++ starterware-taller/drivers/cppi41dma.c 2015-09-01 16:36:10.840799357 -0300 @@ -52,7 +52,6 @@ #include "cache.h" #endif #include "uartStdio.h" -#include "consoleUtils.h" /* ** STATIC FUNCTIONs **/ @@ -2023,10 +2022,10 @@ pend2 = HWREG(USB_OTGBASE + CPDMA_PEND_2_REGISTER); pend3 = HWREG(USB_OTGBASE + CPDMA_PEND_3_REGISTER); -ConsoleUtilsPrintf("\t\t%s: %s = %x\n\n", __FUNCTION__, " pend0 ", pend0); -ConsoleUtilsPrintf("\t\t%s: %s = %x\n\n", __FUNCTION__, " pend1 ", pend1); -ConsoleUtilsPrintf("\t\t%s: %s = %x\n\n", __FUNCTION__, " pend2 ", pend2); -ConsoleUtilsPrintf("\t\t%s: %s = %x\n\n", __FUNCTION__, " pend3 ", pend3); +pend0 = pend0; +pend1 = pend1; +pend2 = pend2; +pend3 = pend3; } Only in starterware-ti/drivers: cpsw.c diff -ruw starterware-ti/drivers/dcan.c starterware-taller/drivers/dcan.c --- starterware-ti/drivers/dcan.c 2013-07-11 18:22:51.0 -0300 +++ starterware-taller/drivers/dcan.c 2015-09-01 16:36:10.840799357 -0300 @@ -1394,6 +1394,35 @@ (extId & DCAN_IFMSK_MXTD)); } + +/** + * \brief This API will get the data length code. + * + * \param baseAdd Base Address of the DCAN Module Registers. + * \param dlc Data length code. + * \param regN