> If you have time to spare, a git bisect would be really helpful. It'll
> probably take about half an hour of testing, though. If you have an
> up-to-date git repository sitting there, start with:
>
> git bisect start
> git bisect bad v0.20
> git bisect good v0.18
>
> After that, you'll be shown a message telling you how many commits are
> in the range. Test the current one (you probably only need to check
for
> the identification issue at startup):
>
> make clean && make && mspdebug uif -j
>
> If that works, type "git bisect good", otherwise "git bisect bad".
> After
> about 9ish tests, the range should hopefully be narrowed to a single
> commit which broke support for your chip.
Good trick! This ends up at:
$ git bisect bad
08cd326e669c49adfa3c60ecc11fe75b2405427b is the first bad commit
commit 08cd326e669c49adfa3c60ecc11fe75b2405427b
Author: Daniel Beer <dlb...@gmail.com>
Date: Fri Jul 6 08:50:44 2012 +1200
Fix support for MSP430F2618.
Breakpoint count is stored as a byte, not a 16-bit word.
:040000 040000 e2aa97b9e85faa22f83b7768190f303e98805f37
80466e633bda25babda3023de04658739be6e1af M drivers
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
