Hi,
I am trying to use E78 modules from Ebyte with US915 frequency bands. The module ships with default EU868 configuration and there is no indication on how to change region parameters. Anyone has exprience with these devices?
Thanks!
Somewhat unusually, they seem to have built broadband supporting circuitry which can do possibly do both in one hardware version. However:
“Notes: our default firmware is LoraWan 868MHz band”
It sounds like you’d need to contact them for an alternate firmware to load.
I’ve experimented with the E78 using the US915 frequency band. Unfortunately, Ebyte is less than helpful when it comes to providing a firmware image for this.
I had to build my own using the vague instructions here:
Then loaded the firmware with an SWD programmer and Cyrpress’ version of OpenOCD.
1 Like
It looks like EByte intentionally blocks access to serial bootloader and SWD pins at firmware level.
What particular SWD programmer do you use ?
From my understanding the default Ebyte bootloader does not support UART programming.
SWD pins are accessible though.
For the SWD programmer I’ve used a FT232H and Raspberry PI GPIO.
One of my modules was stubborn and couldn’t actually get to load the firmware, my other has worked very well.
Have you made a record of what particular firmware revision the E78 module had before you wrote it over ?
My E78 does fully function with stock firmware but does not respond on any of SWD operations. According to PSoC4+ datasheets and ANs when SWD pins have been reassigned by firmware code - the only way to ‘aquire’ SWD pins is to use MiniProg3+ within few milliseconds after Vcc power supply activation.
I’ve read other customer reports who where also not able to aquire E78 by generic SWD debug tools like OpenOCD with ST-LINK or J-LINK. This is why I assume that EByte had started to ship all the E78 modules been ‘factory locked’ at certain point of time.
Unfortunately, I did not note firmware version the modules came with.
They were ordered at the start of May of this year.
On most targets you can force your way in with a probe that asserts the hardware reset. Get the SWD running while code is not executing, and keep the CPU in halt.
Just to make sure that I understood you right way - you have succeeded with:
- this OpenOCD source code
- been built and executed on Raspberry Pi over ‘OpenOCD SWD GPIO
bitbang driver’
is that correct ?
Hi, I’m facing the same problem. Could you share your code please?