BCF2000 'noOS' troubleshooting

25 posts / 0 new
Last post
classicalcheese
classicalcheese's picture
BCF2000 'noOS' troubleshooting

I am posting here because it seems to be a well of knowledge for the B-Control products. Unfotunately I have not had a chance to use the BC Manager software from this site, as my second hand  BCF2000 has been out of service.

I got a second hand BCF2000 with firmware v1.04 installed on it, but when trying to update it with the Behringer software the machine is stuck with 'noOS' (no operating system) on the LCD.
Trying to flash the firmware(v1.10 is all that is available to me) in bootloader mode subsequent times with MIDI-OX (over MIDI) was of no use.
Is there any special way to load the firmware? Help is greatly appreciated. 

Thanks.

Richard Crane
Richard Crane's picture

It’s been a while since I did this but what OS are you using on your computer and how are you connecting your BCF to it 

Mark van den Berg
Mark van den Berg's picture

It's been years since I last looked at the BCF/R's firmware, but I seem to remember I never got Behringer's firmware updater to work either.

"noOS" indicates that the most recent firmware upload was interrupted in the middle.
And since the BCF's USB driver is defined in the firmware, the USB cable is no longer functional.
So the only way out of "noOS" is to upload firmware via a standard MIDI cable.
You can do this easily and reliably from BC Manager.
See under MIDI -> Maintenance -> "Send firmware" in section 10 of the BC Manager manual for all the details.
Further background:

  • Section 4: subsection 2 ("The BCF2000/BCR2000’s firmware")
  • Section 10: "Personality" -> "Bootloader"
  • BC MIDI Implementation.pdf: section 22 (particularly 22.1)

Hope this helps,
   Mark.

classicalcheese
classicalcheese's picture

Richard: I am using Windows 10 and a USB 2.0 to midi cable. 

Mark: thanks for the information. Your documentation is excellent. I will give it a go and update you with what happens. 

classicalcheese
classicalcheese's picture

Mark, 

I could not send the firmware to the device as it could not be detected by the BC Manager, so the buttons were greyed out.
I set the MIDI In/Out for the BCF2000 to those of my USB MIDI interface though the MIDI devices dialog.
The personality is coming up as 'Offline'. I could not detect the device with the 'Refresh connection status' operation. 
Thanks again. I'm glad there's some people that are supporting this great bit of hardware. 

Mark van den Berg
Mark van den Berg's picture

I'm not quite sure what's causing your problem, but the following procedure should work (at least it does for me):

1. Download and install the latest BC Manager version, i.e. 4.0.0 RC 1.
(Version 4.0.0 Beta 1 contained a bug in the "send firmware" routine that would cause an "Integer overflow" error message before any firmware data were sent. Though I gather from your words that you didn't even get that far...)

2. Connect your BCF2000 to your MIDI-to-USB device bidirectionally via the BCF's MIDI IN and MIDI OUT A sockets (not via MIDI OUT B/THRU) and switch the BCF on.

3. From BC Manager's main window: Options -> MIDI devices: enable both the input device and the output device of your MIDI-to-USB device.

Then in BC Manager's B-Controls window:

4. Clear any existing B-Controls via B-Control -> Close selected.
This helps to avoid confusion that could otherwise arise: the "Detect B-Controls" operation (see the next step) doesn't clear any predefined but now defunct ("Offline") devices.

5. MIDI -> Detect B-Controls.
This should find your BCF, with the value in the Firmware column becoming something like "BOOTLOADER 1.0".

6. MIDI -> Maintenance -> Send firmware.
You should select the bcf2000_1-10.syx file here.

Once the upload has finished:

7. Switch the BCF off, then on again.
Its display should say "1.10" briefly on startup.

8. BC Manager: B-Controls: Refresh connection status.
The Firmware column for the BCF should now say "BCF2000 1.10".

Beware: in my experience Windows 7 (I don't know about 10) often changes the BCF/BCR's input and output device names (often by adding weird characters) after you've switched the unit off, then on again.
Whenever this happens, you have to tell BC Manager about the changed names, by enabling them in the "MIDI devices" dialog box and in the "MIDI options" dialog box of the BCF/R in the B-Controls window.

Hope this helps,
   Mark.

classicalcheese
classicalcheese's picture

I have got the BCF2000 up and working again using the BC Manager.
It turned out that my MIDI interface was too cheap for the job.
I purchased a new Roland USB-MIDI interface, and the BCF2000 was detected straight away. 
Thanks for your help. A donation has been made for the use of this excellent software.

Frank

PatMaximum
PatMaximum's picture

Hi Mark.

Attempting to send firmware to hopefully iron out some odd brc2000 habits. Eg am using custom text to send sysex to a JV-1080 and top row button 8 toggles button 6 led when 6 is not an active element. button 8 also emits spurious CCs. So then I redefined btn 8 to send CC. Press it and the first output is the correct CC followed by what looks like a panic load of all notes off, all sounds off, and a pile of unhelpful pitch bend messages.  The hardware hacker in me smells dodgy memory..

Any ideas?

Pat

Have followed all of the above and BCmanager responds with the BEWARE ..has not confirmed acceptance... etc. Midi  error log informs " Error: MIDI system exclusive error Memory segment 2 rejected; address: 002F00; error 1.

Powering BCR off then on again didn't kill it - works normally. Am using Windows 7, a Tascam US-144 midi interface and had exited midiox.

 

 

Mark van den Berg
Mark van den Berg's picture

Attempting to send firmware to hopefully iron out some odd brc2000 habits.

To quote what I wrote in another forum topic:

The BCR performs a firmware check (using a checksum) during startup. The display briefly shows the firmware version (typically "1.10") only if the firmware is fully OK.
So if you see "1.10", it would be utterly pointless to re-flash the firmware. (Somehow that's what a lot of people in situations like this try to do out of desperation. Just don't!)

(I've given the same warning to several other people in different places, but to avoid any further confusion I'm now going to put it in BC Manager's firmware routine itself, and in the manual.)

 The hardware hacker in me smells dodgy memory..

Any ideas?

Whatever the cause of your problems is, it isn't the firmware on the EEPROM chip.
It might be the RAM chip, but this doesn't seem the most likely candidate either, since (as you state) the device appears to work normally in general: your problems are rather specific, i.e. concerning LEDs and MIDI output.

Do only specific elements (buttons/encoders) give problems? If so, there may be a hardware problem with those.
To test all elements, you may want to use BC Manager's "Test hardware" routine, available from the B-Controls window via MIDI -> Maintenance. Press/turn each button/encoder and see what happens. (See the manual for further description.)

Hope this helps,
   Mark.

PatMaximum
PatMaximum's picture

Hi Mark.

Ran BC Manager's Test Hardware and my BCR passed it with flying colors. However it did let me examine the push encoder behaviour more closely which have been erratic since day one, purchased new. Like ya twist 'em slowly and seem ok, yet quick movements may have unpredictable result. Reminds me of those cheap computer mice from the early '90s. Am no stranger to the screwdriver and soldering iron so when the current build is off the bench will venture inside the BCR. Will endeavor to hook up a different encoder to one of the push type to rule in or out dodgy encoder hardware. Will keep ya posted

 

PatMaximum
PatMaximum's picture

My BCR2000 survived open heart surgery. Googled BCR hardware issues and  found some mention of replacing  the push encoders. Other research re using encoders on an arduino pionts at the issue of contact bounce. So, soldered a pair of 100nf caps, one from the "A" contact to ground, the other from the"B" contact to ground of push encoder 8 and viola! Got rid of its erratic behaviour totally. So did the same to the other 7 push encoders with the same result. Then repeated an earlier experiment with the top row buttons of preset 30, setting 6,7 and 8 each with a different CC toggling a value.  6 and 7 behaved as intended but toggling 8 causes 6 and 7 to toggle and emit, toggling 8 toggles and emits 6,7 and 8. This was repeated on the second row buttons with the same result whereas previously the bottom row buttons behaved similarly but button 8 caused emission of 30 or so spurious CC's. Ran out of caps so next time shopping will get a bag of 'em. Next step will be to connect one across each of the top row buttons and see what happens. Will end up putting a cap across every set of contacts in the thing coz I figure that the bit of code that the BCR uses to deal with contact bounce could use a little help. Having said all that, I cannot say that re-seating all the connectors and CPR had any effect. To be continued..

thederekfrank
thederekfrank's picture

I got the dreaded NoOS Screen and have done all the steps. I have tried several Sysex files and even one Behringer sent me directly. I have tried loading it directly into the BCF2000 not in "LOAD" mode, and also in "LOAD" mode. The lights on the BCF says its receiving data and when its done, the screen says 18. Then when I power down and power back up, it goes back to NoOS. 

Am I missing a step to save the data and making it stay? I kind of think its time to make this a boat anchor and maybe even use all the parts to build my own controller with Arduino.

Mark van den Berg
Mark van den Berg's picture

have done all the steps.

Are you talking about the procedure I described in comment #6 in this topic?

I have tried several Sysex files and even one Behringer sent me directly.

There's only one file you should attempt to send, namely bcf2000_1-10.syx, which contains firmware version 1.10 for the BCF2000.
BC Manager's "Send firmware" routine performs various checksum checks on any syx file you tell it to upload to your BCF: if there's anything wrong, BC Manager will refuse to upload the file to the BCF. If BC Manager does agree to upload the file, you can be sure that it contains valid firmware data.

I kind of think its time to make this a boat anchor and maybe even use all the parts to build my own controller with Arduino.

The BCF's bootloader code, which is responsible for the "noOS" message, is on the same EEPROM chip from which the OS is missing, so it seems unlikely there's anything wrong with this EEPROM chip. So the appearance of "noOS" is actually a good sign. It also demonstrates that the RAM and the display are functioning.
In theory there could be something wrong with the MIDI I/O ports, but since the display reacts when you send data to it, this seems unlikely too.
Nothing in what you've said indicates to me that there's a hardware problem with your BCF: it seems to be just missing an OS.

Hope this helps,
   Mark.

thederekfrank
thederekfrank's picture

Behringer sent me 1.07 sysex not 1.10.  That could be the problem.  Does anyone have a link to where I can download 1.10? I looked all over and couldnt find anything.

Also, if I wanted to ignore all of behringers programming and basically just use the knobs and faders and build my own controller, do you think it would be possible?

Mark van den Berg
Mark van den Berg's picture

You didn't answer my question: which program did you use to upload firmware to your BCF?
The reason I'm asking is that Behringer's BCUPDATE.exe simply doesn't work, and BC Manager does.
So if you used BCUPDATE.exe, that would explain all your woes.

Behringer sent me 1.07 sysex not 1.10.  That could be the problem.

No, it couldn't. 1.07 and 1.10 are very similar, so if you didn't succeed in installing 1.07 on your BCF, you won't succeed with 1.10 via the same procedure.

Does anyone have a link to where I can download 1.10? I looked all over and couldnt find anything.

These firmware files used to be available at Behringer's BCF2000 support page, but they took that page down a few months ago.
However, someone has now uploaded the BCF2000 and BCR2000 1.07 and 1.10 firmware files to https://mountainutilities.eu/userfiles/b-control.

Hope this helps,
   Mark.

thederekfrank
thederekfrank's picture

I used BC Manager

Mark van den Berg
Mark van den Berg's picture

I've just tested the "Send firmware" routine of BC Manager 4.0.1 for Windows on my own BCF in "noOS" state:
The routine worked correctly for both firmware 1.07 and 1.10, also when I had kept STORE and LEARN pressed while powering the BCF on (so that the display says "LOAd" rather than "noOS").

Crucially, BC Manager should say "Segments sent: 17: acceptance confirmed: 17" at the end of the upload process.
Do you get this message?
This message indicates that the BCF has accepted all data and (presumably) has written the data to its EEPROM chip.
So then, upon a restart the display should not show "noOS" any more, but should briefly show the version of the firmware you've just uploaded, after which (at least in normal (non-emulation) "B-Control" mode) it should settle at the number of the default preset (e.g. "P- 1").
So if you don't get this "acceptance confirmed: 17" message, something has gone wrong with the upload process (perhaps related to your MIDI interface between the computer and the BCF?).
On the other hand, if you do get this message but on restart the BCF still shows "noOS", there is probably something wrong with the BCF's hardware, in particular its EEPROM chip, or maybe its RAM.

thederekfrank
thederekfrank's picture

I keep getting

error: MIDI system exclusive error

Memory egment 2 rejected; address: 002F00; error

Mark van den Berg
Mark van den Berg's picture

This error probably means there is something wrong with your MIDI setup during the firmware upload process, most likely your MIDI interface.

Some background:
A BCF firmware file like bcf2000_1-10.syx consists of 272 SysEx messages.
Each of these SysEx message consists of 304 bytes, which the BCF converts to 256 bytes of actual firmware data.
The 272 SysEx messages are divided into 17 segments of 16 SysEx messages.
After receiving each segment of 16 SysEx messages, the BCF performs a checksum routine on the data received in these 16 messages.
If the checksum is correct, the BCF writes the received firmware data (16 x 256 = 4096 bytes) to its EEPROM chip and outputs a notification SysEx message confirming acceptance.
If the checksum is not correct, the BCF does not write the data to its EEPROM chip, but briefly shows "Err5" in its display and outputs a rejection message.

Specifically, your rejection message "Memory segment 2 rejected; address: 002F00; error 1" is the rejection message for the very first segment that gets sent.
(This segment is called "2" because the firmware starts at address 002000 on the EEPROM chip: the area before that belongs to the (fixed) bootloader code.)

Since BC Manager's "Send firmware" routine performs the very same checksum routine on any firmware file you ask it to upload to the BCF, the SysEx messages are guaranteed to be correct coming from BC Manager.

So one possible explanation for why the BCF rejects segment 2 is that one or more of the SysEx messages have become corrupted along the way.
The most likely culprit is the MIDI interface between the computer and the BCF.
Each SysEx message consists of 304 bytes, which is longish in "MIDI land".
(It's not for nothing that Roland uses a SysEx protocol where a SysEx message cannot be longer than 256 bytes.)
So there might be MIDI interfaces that don't handle these longish SysEx messages correctly.
(Ironically, the BCF2000 and BCR2000 themselves corrupt any SysEx message received via USB that is longer than 1019 bytes!)

So you might try to check whether your MIDI interface handles long SysEx messages correctly.
E.g. in BC Manager (or MIDI Tools) you can send simple long SysEx messages from the "MIDI System messages" window.
If you loop these messages back to the computer by connecting a MIDI cable between your MIDI interface's output and input sockets, you can see in BC Manager or MIDI Tools' "MIDI input messages" window whether they have been altered in any way.
If they have, you should use a different MIDI interface for the BCF firmware upload procedure.

Alternatively, the firmware upload procedure may be going wrong due to intervening MIDI messages, such as Timing Clock or Active Sensing.
Perhaps the BCF can't handle certain interruptions? I don't know - it would be tricky to test.
You might want to watch the MIDI IN LED of the BCF: it blinks whenever MIDI messages are being received.
In any case, your MIDI interface may be involved here too (though it's debatable whether the BCF or the MIDI interface is to blame).
Many MIDI interfaces have a MIDI Thru facility; it might help to switch this off, if possible.
And again, you might simply try a different MIDI interface.

Hope this helps,
   Mark.

PatMaximum
PatMaximum's picture

Yeah I had the same error,  attempting to send firmware to BCR2000 with BCManager tho didn't have the NOOS issue. However was successful in sending bcr2000_1-10.syx with Bome SendSX however this did not resolve the issue was having with the bcr in emitting spurious CC's - a hardware hack sorted that one.

Mark van den Berg
Mark van den Berg's picture

Of course you can use any one-way SysEx uploading routine (such as Bome SendSX's, or the one offered by BC Manager's "MIDI System Exclusive messages" window) to send firmware to a BCF/R.
However, a one-way upload routine doesn't offer any way of verifying that the BCF/R is actually accepting the data: the routine just keeps sending the data blindly.
And since your BCR already had a working OS beforehand, how did you know afterward that the one-way upload had actually been "successful"? (Unless the firmware version you uploaded differed from the existing version.)

By contrast, BC Manager's two-way "Send firmware" routine halts when the BCF/R indicates it hasn't accepted a particular data segment. But you can't blame the routine for this: that's like shooting the messenger.

thederekfrank
thederekfrank's picture

Thank you for talking about Bome SendSX!!!!!! I haven't tried that software, and sure enough, it fixed it!!!! Nothing else would work. I used BC Manager, MIDI-OX, BCupdate, and after accepting that my BCF2000 was toast, Bome brought it back to life! Thank you, thank you, thank you!!

Mark van den Berg
Mark van den Berg's picture

Glad you managed to bring your BCF back to life!

However, this does beg the question what's so special about Bome SendSX that it worked and none of the others did.
I did know that BCUPDATE doesn't work (though I don't know why), but that even the respectable MIDI-OX didn't work for you is really strange.

Before I read this post of yours, I was going to suggest you try a test build of BC Manager I've made: the "send firmware" routine now waits 100 msec after each individual SysEx message before sending the next. This might avoid problems with MIDI interfaces with small buffer capacities (when the buffer is full, new data can get lost).
But (if I remember correctly) MIDI-OX always waits 50 or 60 msec between SysEx messages, so if that delay wasn't enough in your situation, I don't really know what to think. Perhaps Bome uses an even longer delay, maybe indeed something like 100 msec?
Anyway, I think I'll make the 100 msec delay part of the next version of BC Manager - it can't do any harm...

As a matter of interest: which MIDI interface did you use?

thederekfrank
thederekfrank's picture

I used a Mio iConnectivity. I was beginning to think that was the problem, butit worked with Bome. It was strange, BC Manager failed after just a few seconds, MIDI-OX loaded everything, but when I turned it on again, it would go back to NoOS, but Bome worked. It may have just been a perfect storm with how I did the whole process the one time I used Bome.

Next question: beside OSIMidi Stage, what do you use to get convert MIDI to OSC? I have an XR18 and OSIMidi work with it, but I am not very comfortable paying online for a product and trusting different countries money conversion. IE I am from the US and they take Euros. 

Thanks!

PatMaximum
PatMaximum's picture

Well I'll be darned! Sorry Mark, I didn't mean to shoot any messenger, arrived at this with a typical "now what happens if I try this..." kind of thought. More head scratching. Given that BC manager uses two-way communication with a BCR/F and my BCR has some spurious emission issue seemingly associated with its internal encoder/display matrix circuitry I guess that perhaps BC Manager got tripped up by "left of field" spurious BCR output.