Debugging Gateway Shield Firmware


#1

Hi @eric & community,

I’m continuing my effort to update the Gateway Shield firmware for a custom requirement.

I really need a way to debug my code as I often make a code change that fails after I flash it.

At the very least I want to be able to include some simple debug statements where I make my code changes and have that appear in Serial. e.g.
DEBUG(“Reached this block of code”);

I’m aware that the Gateway Shield does not support serial debugging, but as my Photon supports it, is there someway I can get my debug messages from the Gateway firmware onto the Photon so it see it out using “particle serial monitor”?

I came across this topic by @gruvin but this relates to DK firmware:

Will this work for the Gateway Shield as well?

or is there another way I can do this?

Thanks,


#2

Hello again.

The gateway code already sends a bunch of debug code out the USB serial
port – stock standard – example: debugPrint(“STARTING!”);. It’s at 38400
baud, by default. See the setup() function. So you can just use that.
This is a custom, basic debug scheme for the gateway shield code, of course.

The references in the stuff you copied from the community forum are for
debugging the Bluz’s main firmware.

Bryan.


#3

@gruvin thanks for the reply.

As far as I know, The debugPrint() method is only part of the Particle Photon’s “User App”, as the Photon supports Serial print out I can debug the User App code like this.

What I need is a way to debug the Gateway Shield Firmware, e.g. write some debug here:

And have that debug flow up to the Photon’s “User App” so I then use the debugPrint() method to print it out to Serial.

I know its possible as the Gateway Shield Firmware already sends stuff up to the User App to print it out on Serial, e.g. the gateway shield ID

But I’ve not had any luck reverse engineering this so far.

Have you done anything like this when you worked with the Firmware?

Thanks.


#4

Mark

Oh, right. I thought you meant the firmware on the photon, on gateway the
gateway shield.

I’m not sure how to debug the gateway firmware. I’ve never needed to so
far, sorry. There is one routine in there I would update eventually for the
TCPClient support. But for now, the gateway Photon code just works around
it, and simply enough.

Hmmm. Are you sure you need to be delving into the gateway firmware? The
gateway NRF’ merely shuffles low level BT data packets between DKs and the
gateway’s Photon. All the user data protocol handling is done on those, not
in the gateway NRF at all. Unless you’re planning on implementing bluetooth
protocols on the gateway itself, I cannot imagine why you would need to
make changes in the gateway NRF firmware. Wait … did you mention having
BT audio devices register with the NRF on the gateway? Be aware that these
modules can only handle a maximum of eight BT connections. It one is in use
for, say audio, then that’s one less DK that can connect, for example.
(Assuming I understand things correctly. Pretty sure.)

You should be able to implement anything else you need between the DK
firmware and the Photon sketch on the gateway. For example, I implemented
the entire deep DK firmware TCPClient functionality without touching the
gateway firmware. So again, I really don’t think you want to be dipping
your toes in there.

For things that don’t already have Spark Wiring implementations to
re-implement (like TCPClient did) – that is, completely new protocols for
some kind of custom device, Eric’s idea is to shuffle said custom data back
and forth between DK and Photon on the gateway shield using the custom
data, “channel”, as already implemented in the DK firmware and in the
Gateway Shield Photon sketch.

Do you know about that already – or is this the first you’ve heard of it?
The exact name of the functions elude me just now. But I can look it
tomorrow and point you in the right direction if needed. There are a pair
of functions on the DK end of things for sending and receiving custom data
packets and something similar implemented in the gateway Photon sketch –
the receiving end being an empty function declaration with a comment
something like, “anything send using the CUSTOM_DATA channel will arrive
here.”

Sorry, this is all off the top of my head from stuff I haven’t actually
seen for a couple months. Hope it’s all accurate enough!

I’m outta time. Gotta run. Hope it helps some!

Bryan.


#5

There is currently no way to send debug messages to the Photon to print out. You could technically implement one. If you wrote a function that just pretended to be the custom data service (so append 0x04 to the front of the byte array you want to print) and then send it through the SPI bus, you can have the Photon print out all those messages onto its Serial port. Or, better yet, just make a new data_service (copy custom_data_service.c/.h and add a new type of 0x05) and have the Photon handle the new type.

You can also send serial data directly from the nrf51 on the gateway shield, but it requires a USB to Serial adapter and some soldering. The TX/RX pins labeled on the gateway shied are just that, so you can use
Serial1 to send messages from the code.

There is a write up on this here: https://github.com/bluzDK/bluzDK-firmware/blob/develop/docs/debugging.md

It requires some slight shifting of the firmware regions, but those are small changes. If you want to pursue that path, let me know.


#6

Mark

I think the following failed to send via the form gateway, which complained
that the body was too short and not descriptive enough. So this time, I’m
including this header text, ffs LOL …

ERRATA …


#7

Thanks @eric

I’ll try using the SPI bus to send data into the Photon for now as a CUSTOM_DATA_SERVICE.

When you say:
…so append 0x04 to the front of the byte array you want to print) and then send it through the SPI bus

Do you mean call the below method and prepend 0x04 to the start of ble_read_buffer?

spi_slave_set_tx_buffer(p_client, SPI_BUS_DATA, p_client->ble_read_buffer, p_client->ble_read_buffer_length);

Most of my changes are in client_handling.c


#8

Yes, if you do that, then all data should go straight to the Photon and be handled in the custom data callback handler.