Two wrongs make a working prototype

 In Blackfin, embedded C

I had an interesting problem show up when I was working on a project at the beginning of the year.  It involved an Analog Devices Blackfin 51x series processor.  We went to transition to their new IDE and that’s when we started noticing problems with the Flash RAM.

The Backstory

I was bringing up a new board with an Analog Devices’ Blackfin 514 on it the last part of 2012 and the first part of 2013.  We got the code working and got it programming the flash RAM and booting from it using their VisualDSP++ IDE.  Since this was a new design, we wanted to transition to their Cross Core Embedded Studio (CCES) that is based on Eclipse.  We got the base program transitioned over and then tried programming the flash RAM and booting from it.  That didn’t go so well.  I reprogrammed it and verified what was programmed.  Let’s try this again… and again, the old program ran.  We swapped back to VisualDSP++ and it didn’t see the new code.  What gives?  To understand my level of frustration, realize that this was a period of more than aweek as it was a 24 hour round trip for answers to tech support questions via India (I think, the replies liked to show up at 3 AM MST).

… and now, the rest of the story

Thank you for the introduction Paul Harvey.  We slowly got the issue escalated.  I sent traces from my oscilloscope of the memory lines.  I was finally talking with the author of their flash programming driver.  I sent memory dumps back and forth from VisualDSP++ and CCES.  We did that a few times and had some of their engineers look at our schematic.  We finally had a lead.  We had based our design of the BF518 Ez-board.  If you look at their documentation, page 94, zone 2A, there are several pull-up resistors on the AMS lines between the switches and flash RAM.  When we designed the board, we assumed thought that the pull-up resistors were there to keep the lines from floating when they were disconnected from the processor.  It turns out that when the processor first resets, some of those lines are not configured as AMS lines, but are floating.  Alright.  Now we know that is a problem.  If that is the case, then why were we able to program the flash RAM in VisualDSP++ successfully.

So, why did VisualDSP++ successfully program the flash RAM?  It turns out that when the code for the flash driver for the BF518 Ez-board was designed just for the BF518, not the BF51x series.  So, when we went in and changed it to compile for the BF514, there was a preprocessor directive that no longer compiled in the code to set all the AMS lines as active.  That was the second “wrong”.  We were lucky that with some of the AMS lines floating, they reliably floated in a particular direction so we ended up programming and reading the same 1 MB block of flash memory… which was not actually the first block of flash memory.  We didn’t notice this because our program was small enough that we didn’t need more than the one block of memory.

When transitioning to CCES, we fixed the wrong in the flash RAM driver which caused our error to show up.  We soldered on the pull-up resistors and things started working with CCES… and failing with VisualDSP++.  We figured out what needed to be changed so the correct portions of the VisualDSP++ driver would compile and work.  Things were good after that.

The moral of the story is, “Yes we put those there for a reason, but not the one you think.”

Leave a Comment

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Start typing and press Enter to search