Discussion:
Bug fix: DMA regression for STM32 f10x [1 Attachment]
(too old to reply)
Laurent Latil
2013-05-15 15:06:47 UTC
Permalink
Hi,

Here is a fix for the DMA problem encountered on 'hymini-stm32', but
concerns the whole STM32 f10x family.
When applied, the SD card can be accessed successfully, filesystem
mounted, etc.
('git bissect' is a *great* tool by the way...)

Regards.
--
- Laurent Latil -
Gregory N
2013-05-15 22:19:33 UTC
Permalink
Hi, Laurent,
Post by Laurent Latil
Here is a fix for the DMA problem encountered on 'hymini-stm32', but
concerns the whole STM32 f10x family.
When applied, the SD card can be accessed successfully, filesystem
mounted, etc.
('git bissect' is a *great* tool by the way...)
Yes, that is a problem thanks. The change is checked-in.

This had me really puzzled because I know that STM32 F1 DMA has worked. It has worked for several years now!

But I see that the error was introduced here (way back in February of 2012):

http://sourceforge.net/p/nuttx/git/ci/19b930ec0781b037b3b7fdde0a0fddc798861fe8/tree/nuttx/arch/arm/src/stm32/chip/stm32f10xxx_dma.h?diff=d7ea71908198fbe6ed03df12eb3ce2b77a8945dc

Looks like an STM32 F4 change that included a blind F1 change as well:

http://sourceforge.net/p/nuttx/git/ci/d7ea71908198fbe6ed03df12eb3ce2b77a8945dc/

Sorry for the inconvenience. It has been there long enough that I fear there now could be other errors that assume these bad DMA register definitions.

Greg
llatil
2013-05-16 21:03:37 UTC
Permalink
Hi Gregory,
Post by Gregory N
This had me really puzzled because I know that STM32 F1 DMA has worked. It has worked for several years now!
I know that, as it worked perfectly on the Nuttx version I used until now. That's why I took time to track it down (and because I really need SD card support too)

As I wrote the regression was tracked through a bisect.
And this brings me a question/remark about the Nuttx GIT repository:
there are no tags (apparently) in the Nuttx history.

So, how can we retrieve the exact source code for a given Nuttx revision ?

PS: I am a long time SVN user, and I still struggle a little bit with GIT. So may be I missed something obvious.

- Laurent Latil -
Gregory N
2013-05-16 21:20:30 UTC
Permalink
Laurent,
Post by llatil
Post by Gregory N
This had me really puzzled because I know that STM32 F1 DMA has worked. It has worked for several years now!
I know that, as it worked perfectly on the Nuttx version I used until now. That's why I took time to track it down (and because I really need SD card support too)
As I wrote the regression was tracked through a bisect.
Thank your for finding and fixing that! It looks like the STM32 F1 DMA has been broken since Feb, 2012!
Post by llatil
there are no tags (apparently) in the Nuttx history.
So, how can we retrieve the exact source code for a given Nuttx revision ?
PS: I am a long time SVN user, and I still struggle a little bit with GIT. So may be I missed something obvious.
I recently converted everything from SVN to GIT by popular demand. This decision was based on better server NuttX users; personally, I think that SVN is a better choice for a one-person repository.

In the nuttx/ReleaseNotes, there are SVN revision numbers for each release. But those won't help too much now. But here is a trick that works for me.

1. CD into the NuttX directory, then
2. git log ReleaseNotes

That will get the long GIT UUID for each release. For the older SVN releases, it should also give you the mapping to the SVN revision number (but not for the later commits).

Normally, the update to the release notes is the very last commit before the release so this UUID can be used instead of the SVN revision number.

Greg
Gerd v. Egidy
2013-05-17 07:51:39 UTC
Permalink
Hi Greg,
Post by Gregory N
Post by llatil
there are no tags (apparently) in the Nuttx history.
In the nuttx/ReleaseNotes, there are SVN revision numbers for each release.
But those won't help too much now. But here is a trick that works for me.
1. CD into the NuttX directory, then
2. git log ReleaseNotes
That will get the long GIT UUID for each release. For the older SVN
releases, it should also give you the mapping to the SVN revision number
(but not for the later commits).
Normally, the update to the release notes is the very last commit before the
release so this UUID can be used instead of the SVN revision number.
this is a good way for finding the corresponding git UUIDs for the older
releases.

But please consider adding git tags for future releases. That would make
bisecting and other log-searching tasks easier in the future.

Adding a regular tag in git is easy, just run this after the last commit:

git tag -a <tagname>

Using annotated tags (-a) makes sure they always get pushed out without any
special options to remember.

The even better alternative would be:

git tag -u <key-id> <tagname>

This will create a gpg signed tag using the gpg key <key-id>. This has the
advantage that you can be sure that noone has tampered with the repository up
to the signed tag.

Kind regards,

Gerd
Gregory N
2013-05-17 13:47:15 UTC
Permalink
Hi, Gerd,
Post by Gerd v. Egidy
Post by Gregory N
Post by llatil
there are no tags (apparently) in the Nuttx history.
In the nuttx/ReleaseNotes, there are SVN revision numbers for each release.
But those won't help too much now. But here is a trick that works for me.
1. CD into the NuttX directory, then
2. git log ReleaseNotes
That will get the long GIT UUID for each release. For the older SVN
releases, it should also give you the mapping to the SVN revision number
(but not for the later commits).
Normally, the update to the release notes is the very last commit before the
release so this UUID can be used instead of the SVN revision number.
this is a good way for finding the corresponding git UUIDs for the older
releases.
But please consider adding git tags for future releases. That would make
bisecting and other log-searching tasks easier in the future.
git tag -a <tagname>
Using annotated tags (-a) makes sure they always get pushed out without any
special options to remember.
git tag -u <key-id> <tagname>
This will create a gpg signed tag using the gpg key <key-id>. This has the
advantage that you can be sure that noone has tampered with the repository up
to the signed tag.
I used the git log ReleaseNotes to create a bash script to tag all of the previous releases. That should be in place now. Hmmm.. I see I forget the -a and -m options in my script so I ended up with lightweight tags. I suppose that is sufficient for this purpose.

Greg
Gregory N
2013-05-17 14:21:46 UTC
Permalink
Hi, again,
Post by Gregory N
I used the git log ReleaseNotes to create a bash script to tag all of the previous releases. That should be in place now. Hmmm.. I see I forget the -a and -m options in my script so I ended up with lightweight tags. I suppose that is sufficient for this purpose.
I modified my script, removed those lightweight tags, and created a normal tags. I was puzzled for some time because I couldn't see those tags when I rebased on other machines. I didn't release that was a special for of git push that you have to use to push tags into the repository: git push origin --tags.

Greg
Gerd v. Egidy
2013-05-17 14:56:12 UTC
Permalink
Hi Greg,
Post by Gregory N
Post by Gregory N
I used the git log ReleaseNotes to create a bash script to tag all of the
previous releases. That should be in place now.
Thanks a lot. This is even better.
Post by Gregory N
Post by Gregory N
Hmmm.. I see I forget
the -a and -m options in my script so I ended up with lightweight tags.
I suppose that is sufficient for this purpose.
I modified my script, removed those lightweight tags, and created a normal
tags. I was puzzled for some time because I couldn't see those tags when I
rebased on other machines. I didn't release that was a special for of git
push that you have to use to push tags into the repository: git push
origin --tags.
Yeah, the difference between lightweight tags and annotated tags is a common
pitfall. It hit me several times when I started to use git.

After some time using it I came to the conclusion that annotated (or gpg-
signed) tags are the best solution for stuff that doesn't change ever again.
Like a release: once you uploaded it to the website it's out and you can't
change it anymore in a sane way.

I use lightweight tags for cases where the tag can move, like "current beta
status" or "last known commit which doesn't have bug xx".

But this is just my way of using it, other preferences and usescases are valid
too.

As long as there are any kind of tags I'm happy ;)

Kind regards,

Gerd
--
Address (better: trap) for people I really don't want to get mail from:
jonas-K4Lox0BdAqn6SQ/niu2adgC/***@public.gmane.org
Gregory N
2013-05-17 15:21:23 UTC
Permalink
Hi, Gerd,
Post by Gerd v. Egidy
Post by Gregory N
Post by Gregory N
I used the git log ReleaseNotes to create a bash script to tag all of the
previous releases. That should be in place now.
Thanks a lot. This is even better.
Post by Gregory N
Post by Gregory N
Hmmm.. I see I forget
the -a and -m options in my script so I ended up with lightweight tags.
I suppose that is sufficient for this purpose.
I modified my script, removed those lightweight tags, and created a normal
tags. I was puzzled for some time because I couldn't see those tags when I
rebased on other machines. I didn't release that was a special for of git
push that you have to use to push tags into the repository: git push
origin --tags.
Yeah, the difference between lightweight tags and annotated tags is a common
pitfall. It hit me several times when I started to use git.
After some time using it I came to the conclusion that annotated (or gpg-
signed) tags are the best solution for stuff that doesn't change ever again.
Like a release: once you uploaded it to the website it's out and you can't
change it anymore in a sane way.
I use lightweight tags for cases where the tag can move, like "current beta
status" or "last known commit which doesn't have bug xx".
But this is just my way of using it, other preferences and usescases are valid
too.
As long as there are any kind of tags I'm happy ;)
A bonus is that the SourceForge GIT page now allows you select any version by its release name: http://sourceforge.net/p/nuttx/git/ci/master/tree/

Even back to the first release: http://sourceforge.net/p/nuttx/git/ci/nuttx-1.0/tree/nuttx/ . That really brings back some memories. The only device driver in drivers/ is /dev/null. The only example/ was the OS test.

Greg
llatil
2013-05-17 20:34:39 UTC
Permalink
Greg,

Many thanks for having added tags in the GIT history !
They would be very useful should anybody need to dig in previous releases (even back to v1.0... :-) ).

Thanks to Gerd also for his infos & best practices hints on GIT tags usage.

- Laurent -

Daniel O'Connor
2013-05-17 10:06:42 UTC
Permalink
Post by Gregory N
Post by llatil
Post by Gregory N
This had me really puzzled because I know that STM32 F1 DMA has worked. It has worked for several years now!
I know that, as it worked perfectly on the Nuttx version I used until now. That's why I took time to track it down (and because I really need SD card support too)
As I wrote the regression was tracked through a bisect.
Thank your for finding and fixing that! It looks like the STM32 F1 DMA has been broken since Feb, 2012!
Thanks from me too :)
I haven't had time to try debugging it.

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Loading...