Re: PWM driver tested in RTEMS with RGB

[punit vara]

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

[punit vara]

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

[punit vara]

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

[Martin Galvan]

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

[Chris Johns]

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

[punit vara]

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

[Chris Johns]

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

[Chris Johns]

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

[Gedare Bloom]

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

[punit vara]

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

[Martin Galvan]

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

[punit vara]

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_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 

Re: PWM driver tested in RTEMS with RGB

[Martin Galvan]

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_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.