The idea of verification using certificates is that a trust path is build towards a trust anchor - usually also just a certificate. The trust anchor may also be linked to some additional name constraints for the underlying certificates. Trust path (certificate chain) validation is listed in the X.509 specifications.
It is of course possible to verify the signature of anything as long as the verifier has access to the public key. Anybody - including an attacker - can however create a key pair, a (self signed) certificate or certificate tree and create a signature - so any certificate included with the signature cannot be trusted by itself. The idea of PKIX is that you do not just verify the signature but that you also verify all the certificates up to a trusted certificate. The certificates included with the signatures are by themselves not trusted.
Signature verification is only part of the full verification process though, the certificates themselves also need to be validated and preferably the status of the certificates should be verified. The latter is of course tricky for embedded applications as the embedded device may not have access to a Certificate Revocation List (CRL) or an Online Certificate Status Protocol.
What's very likely required of your software is that you supply it a certificate or set of certificates that together form a trust path. The included certificate may be part of that if there is a 1:1 situation where only one certificate can do the signing. Otherwise the chain usually contains intermediate CA and/or root certificates. A quick look at the changelog for the software shows that there was a recent fix regarding intermediate certificates for instance.