Did I just brick my Focbox? Heeelllppppp!

I have 2 focboxes. On one everything works perfectly but not on the other one. In any case I tried different cables but none of them worked. Yes, all my USB cables can be used for data transfer.

1 Like

I second this. This is not an USB issue. I do believe we rule that out early on in the discussions.

@taz Can you please share the images of the PCB here? Front and back required

I received logs from @taz and I can confirm that VESC stopped responding for some reason during TCP Bridge session. I can’t see exactly when VESC stopped responding, because log file contains only data coming from the computer (one side). I will add logging for the other direction as well.

My guess that it was here and the last command that you did was Write App Configuration (02a310)

[I 14:05:45.550] read: 02a31000000003e8000000000100c8020403466a(20)
[I 14:05:45.559] read: 60003e19999a3f84189340029fbe3fc4bc6a0101(20)
[I 14:05:45.569] read: 0000000000000000023e99999a3dcccccd010145(20)
[I 14:05:45.576] read: 3b8000003e19999a3f6666664040000040000000(20)
[I 14:05:45.584] read: 3f66666640400000010100000000000000000000(20)
[I 14:05:45.592] read: 0000023e99999a3dcccccd0000453b800001f400(20)
[I 14:05:45.600] read: 01c200013e19999a3f6666663e99999a453b8000(20)
[I 14:05:45.608] read: 0000000000000000020000453b80000203010003(20)
[I 14:05:45.615] read: 4cc6c70001101e03(8)
[I 14:05:45.674] read: 02011fe3de03(6)
[I 14:05:46.289] read: 02011fe3de03(6)
[I 14:05:46.373] read: 02011fe3de03(6)
[I 14:05:46.749] read: 02011fe3de03(6)
[I 14:06:42.959] Setting PositionSource.active to true
[I 14:06:48.249] TCP disconnected 0xbf0bb198
[I 14:06:48.267] new TCP connection 0xdd92e340
[I 14:06:48.643] read: 020100000003(6)
[I 14:07:13.525] Setting PositionSource.active to false
[I 14:07:13.544] unpair: device=0xbfb53240, esc=0xbfa7af70
[I 14:07:13.544] pair: device=0xbfb53240, esc=0xc35fbb00
[I 14:07:13.545] Ask.startRt()
[I 14:07:13.552] virtual TCP::~TCP()
[I 14:07:13.553] TCP disconnected 0xdd92e340
[I 14:07:30.845] [NRF_LOG] <warning> app: RT TIMED OUT 1

[I 14:07:31.359] [NRF_LOG] <warning> app: RT TIMED OUT 1

[I 14:07:31.869] [NRF_LOG] <warning> app: RT TIMED OUT 1

[I 14:07:32.350] [NRF_LOG] <warning> app: RT TIMED OUT 1
1 Like

Should I be looking at anything in particular?

20181009_202202

20181009_202125

Ok, I received the st-link one day early so went to town. 20181009_222529 20181009_222514

Soldered 3 pins ( DIO - GND - CLK) , 2 from one side of the PCB and 1 from the other side since otherwise the connector would not fit so close together. Uploaded the boot loader then the firmware.bin and then proceeded with the VESC tool as usual. Soldering the pins was a bitch due to all the silicone on the PCB. @CarlCollins you should really do something about this. Having to solder on a PCB to upload the bootloader is not what I would consider appropriate. Anyway, the bloody thing now works.

4 Likes

I don’t think it is focbox issue… Never had focbox clearing itself or etc thing to happen.

I did not mean it was a foxbox issue. Why this happened I have no idea, maybe it was the metr pro module, maybe it was something I did wrong. The fact is that the esc was bricked and instead of just opening the case and connecting to some pins I had to solder pins directly on a silicone covered area of the PCB.

1 Like

Well it’s really rare case when you would need to reflash the bootloaders… It’s purpose to be always available and its flashed only once in manufacture place so that’s why you should be even happy it has holes, most other electronic devices has some test points scattered throughout the board.

If you read this thread and all the other threads in this forum you will see I am not the only one to have this happen to his vesc based esc.

1 Like

Nice to hear that everything working now again :+1:

2 Likes

I was thinking the same thing. Having pins there by default would have been nice. either way, great news I heard all day! I got to wait one more day for me st-link.

1 Like

Yes agree, to some extent. Having something is better than nothing. But yea, would have been better if they just included a pin section.

I am saying that this is more related to common item in all those issues: Using metr to reprogram parameters or flash it and etc things. I don’t use it so I can’t tell anything more :slight_smile:

Guessing from log I think it entered write app config command, was writing remaining bytes and when disconnected then connected back and wrote bytes of new command which continued the same command which was opened before disconnection and overwrote some stuff in memory or etc can’t tell more as I don’t remember how vesc handles commands anymore. But I think the issue is that app disconnected in the middle of the command and when started sending new command bytes to same opened command byte command or etc :thinking:

1 Like

@taz Glad that everything is back in working order again! For the ST-Link flashing, actually, FOCBOX comes with the pre-installed bootloader and 2 out of 10 people only suffer to this rare condition. Also, FOCBOX is initially a Raptor 2 replacement item.

I would not call a condition that happens to 20% of the FOCBOX owners rare.

@taz As per my knowledge and experience while working with Enertion. Condition is quite rare because most of the customers use USB connection to flash firmware without any issues.

Makes sense. But the same thing happen to me. However, I only did “read” . No write commands. So I guess it’s read and write. There’s obviously and issue/bug with the app mode change section. The developer is looking into it, We only sharing experience so it can be promptly resolved.

1 Like

One thing you can’t blame FocBox as its only hardware… It’s software and it can affect any vesc :wink:

I’m back in business fellas ! Zoom zooom!

4 Likes